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Abstract 


Objective: 

The  purpose  of  the  A-RCI  case  study  is  to  create  a  learning  vehicle  that 
describes  spiral  development  through  Open  Systems  Design,  which  then  can  be 
used  for  training  and  education  of  acquisition  practitioners  and  future  acquisition 
leaders.  The  study  considers  such  aspects  as  the  PMO  cultural  environment, 
management  techniques,  open  systems  processes  and  controls,  appropriate  open 
systems  metrics,  resource  impacts,  business-case  analysis  (ROI),  user  and 
contractor  participation,  logistics  planning,  and  required  participant  training. 

Summary: 

Acoustic  Rapid  COTS  Insertion  (A-RCI)  is  a  success  story  in  the  use  of 
Modular  Open  Systems  Approach  (MOSA)/Open  Architecture  (OA) — beginning  with 
towed-array  sonar  on  688  Class  Submarines  and  later  encompassing  all  sonar 
systems  on  all  attack  submarines,  some  surface  ship  sonar  applications  and  even 
aviation  anti-submarine  warfare.  The  DoD  has  long  considered  Open  Systems 
Design  a  “best  practice”  that  should  be  used  during  system  development.  However, 
as  is  often  the  case  with  best  practices,  the  “lessons  learned”  have  not  been 
trumpeted  widely  across  DoD  acquisition  organizations;  distillation  of  the  reasons  for 
success  in  A-RCI  has  not  occurred  as  yet,  and  the  A-RCI  techniques  used  in  Open 
Systems  Design  are  not  widely  known  and  applied  in  other  program  offices  or  taught 
in  our  institutional  “schoolhouses.”  One  way  for  interested  parties  to  learn  the 
practice  of  Open  Systems  Design  successfully  is  through  case  study.  The  purpose 
of  this  A-RCI  case  study  is  to  create  a  learning  vehicle  for  the  application  of 
MOSA/OA  which  then  could  be  used  for  training  and  education  of  acquisition 
practitioners  and  future  acquisition  leaders. 

The  study  considers  such  aspects  as  the  PMO  cultural  environment, 
management  techniques,  open  systems  processes  and  controls,  appropriate  open 


systems  metrics,  resource  impacts,  the  interface  with  JCIDS,  user  and  contractor 
participation,  logistics  planning,  operational  testing,  and  required  participant  training. 

DoD  Key  Technology  Areas: 

Spiral  Development,  Advanced  Processing  Builds,  Federated  Software 
Systems,  COTS  Processors,  Open  Architecture,  Joint  Capabilities  Integration  and 
Development  System  (JCIDS),  Maintenance  Free  Operating  Period,  Reduction  in 
Total  Ownership  Cost  (R-TOC),  System  Acquisition;  Technical  Refresh. 

Keywords: 

Advanced  Processing  Builds,  Modular  Open  Systems  Approach,  Software 
Acquisition,  Software  Development,  Joint  Capabilities  Integration  and  Development 
System  (JCIDS),  System  Lifecycle  Cost  (LCC),  Spiral  Acquisition,  COTS 
Processors,  Maintenance  Free  Operating  Period  (MFOP),  Reduction  in  Total 
Ownership  Cost  (R-TOC),  Total  Ownership  Cost  (TOC). 
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I.  Executive  Summary 

A.  Background 

In  the  mid-1990s,  the  submarine  community  recognized  the  impending  loss  of 
U.S.  technical  superiority  in  submarine  acoustics  when  foreign  submarines  began  to 
exhibit  major  reduction  in  noise  signature.  This  resulted  in  a  critical  need  to  improve 
acoustic  sensing  systems  to  better  identify  and  track  foreign  submarines.  Although 
new  capability  was  critically  needed,  required  resources  were  not  available  to 
support  the  developmental  effort.  Critical  need  and  the  absence  of  sufficient  funding 
constituted  a  crisis — demanding  a  revolutionary  approach  to  achieve  necessary 
technological  improvement. 

B.  A-RCI/APB  Method 

The  approach  came  to  be  called  A-RCI — Acoustic  Rapid  COTS 
Insertion/Advanced  Processing  Build,  which  might  be  characterized  in  the  following 
manner: 

•  A-RCI  used  a  modular  open  systems  approach  (MOSA).  Hardware  and 
software  development  would  progress  on  different  paths  and  time  lines. 
Key  interfaces,  standards,  and  protocols  would  be  rigorously  controlled  as 
necessary  to  insure  that  different  modules  would  work  together. 

•  Commercial-Off-The-Shelf  (COTS)  technology  would  be  encouraged,  and 
software  reuse  would  be  accomplished  where  feasible. 

•  Innovative  solutions  would  be  sought  from  a  deliberately  broadened  array 
of  participants,  including  defense  contractors.  Government  labs, 
academia,  and  small  innovative  businesses. 

•  Technical  performance  would  be  demonstrated  by  testing  against  known 
(that  is,  operationally  encountered  and  actually  recorded)  real-world 
performance  data. 

•  Technical  decisions  would  be  validated  by  peer  review. 
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1.  A-RCI/APB  Benefits: 

•  A-RCI  yielded  major  performance  and  logistics  improvements.  A- 
RCI/APB  regained  acoustic  superiority.  The  maintenance  burden  of  the 
A-RCI/APB  systems  was  reduced  through  a  new  maintenance  approach. 

•  A-RCI/APB  lifecycle  cost  was  lower  as  a  consequence  of  reduced  cycle 
time,  software  reuse,  transition  to  COTS  processors,  maintenance-free 
operating  periods  while  deployed,  reduced  spare  part  requirements,  and 
reduced  maintenance  training.  The  lifecycle  cost  of  A-RCI/APB  has 
improved  by  nearly  5:1  over  its  predecessor  system. 

•  Software  and  hardware  improvements  could  be  implemented  in  a 
significantly  reduced  cycle  time.  Software  Advanced  Processing  Builds 
were  developed  annually  and  improved  COTS  processors  acquired 
biannually.  These  rates  supported  software  updates  of  each  submarine 
every  two  years  and  installation  of  new  processors  every  four  years. 

2.  Obstacies: 

•  Traditional  end-to-end  operational  Testing  (OT)  was  not  a  good  fit  for  A- 
RCI/APB.  The  amount  of  OT  became  a  major  burden  and  an  obstacle  to 
the  rapid  op  tempo  of  A-RCI/APB  development. 

•  The  Joint  Capability  Integration  and  Development  System  (JCIDS) 
reviews  occurred  at  a  slower  pace  than  the  A-RCI/APB  op  tempo.  The 
accommodation  was  to  conduct  annual  JCIDS  reviews  for  A-RCI/  APB, 
synchronized  to  sequential  developmental  spirals. 

•  A-RCI/APB  required  less  funding  than  would  have  been  required  using  a 
traditional  approach,  but  additionally,  the  funding  profiles  were  shaped 
differently.  Continuous  streams  of  RDT&E,  Procurement,  and  Operations 
and  Support  accounts  were  required  to  support  A-RCI. 

C.  Conclusions 

The  A-RCI/APB  case  study  arrived  at  the  following  conclusions  and 
recommendations. 

1.  A-RCI  has  successfully  applied  MOSA,  deriving  major  performance 
and  logistics  improvements. 

2.  A-RCI  demonstrated  significant  Total  Ownership  Cost  or  system 
Lifecycle  Cost  benefits. 
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3.  The  A-RCI/APB  example  shows  that  MOSA  can  be  applied 
successfully  to  a  legacy  system. 

4.  A-RCI/APB  demonstrates  that  modular  upgrades  can  be  accomplished 
very  rapidly  through  spiral  development,  in  contrast  to  the  longer 
duration  needed  for  traditional  systems  development. 

5.  A-RCI/APB  experience  suggests  there  are  operational  test  issues  that 
must  be  worked  out. 

6.  The  op  tempo  of  A-RCI/APB  and  the  pace  of  JCIDS  suggest  possible 
synchronization  issues  that  should  be  evaluated  to  ensure  appropriate 
joint  reviews  proceed  without  delaying  the  spiral  development  process. 

7.  Funding  implications  of  A-RCI  need  to  be  studied  and  understood. 
Traditional  funding  profiles  do  not  support  the  A-RCI  example. 
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II.  Background 


In  the  mid-1990s,  the  submarine  community  recognized  the  impending  loss  of 
U.S.  technical  superiority  in  submarine  acoustics  when  foreign  submarines  began  to 
exhibit  major  reduction  in  noise  signature.  This  resulted  in  a  critical  need  to  improve 
acoustic  sensing  systems  to  better  recognize  foreign  submarines.  Although  new 
capability  was  critically  needed,  required  resources  were  not  available  to  support  the 
developmental  effort.  Critical  need  and  the  absence  of  sufficient  funding  constituted 
a  crisis — demanding  a  revolutionary  approach  to  achieve  necessary  technological 
improvement.  See  Figure  1 . 


Figure  1.  The  “Crisis” — Siides  Extracted  from  a  Briefing  by  Dr.  John 

Stapleton^ 

The  approach  came  to  be  called  A-RCI — Acoustic  Rapid  COTS  Insertion, 
which  might  be  characterized  in  the  following  manner: 

•  A-RCI  uses  modular  open  systems  approach  (MOSA). 

•  Hardware  and  software  would  progress  on  different  paths  and  time  lines. 

•  Key  interfaces,  standards,  and  protocols  would  be  rigorously  controlled  as 
necessary  to  insure  that  different  modules  would  work  together. 


^  John  Stapleton,  Briefing:  “APB/A-RCI  Performance  Driven  Acquisition  Reform  for  Undersea  Warfare 
Superiority,”  26  September  2006,  Slide  2. 
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•  Commercial-Off-The-Shelf  (COTS)  products  would  be  encouraged  and 
software  reuse  would  be  accomplished  where  feasible. 

•  Innovative  solutions  would  be  sought  from  a  deliberately  broadened  array 
of  participants,  including  defense  contractors,  Government  labs, 
academia,  and  small  businesses. 

•  Technical  performance  would  be  demonstrated  by  testing  against  known 
(that  is,  operationally  encountered  and  actually  recorded)  real-world 
performance  data. 

•  Technical  decisions  would  be  validated  by  peer  review. 

The  A-RCI  approach  demanded  a  new  way  of  doing  business. 

•  Technical  approaches  must  compete  on  a  level  playing  field. 

•  Contractual  mechanisms  must  be  established  to  address  not  only 
competition,  but  also  cooperation  among  winning  competitors  once  the 
selections  were  made. 

•  Intellectual  property  rights  and  the  sharing  of  information  must  be  carefully 
structured  to  achieve  fairness  as  well  as  practicality. 

•  Rapid  improvement  must  be  brought  to  fielding  via  demanding  schedules. 

•  The  Navy’s  relationship  with  the  prime  contractor  must  change 
dramatically. 

•  The  submarine  user  community  must  be  intimately  involved,  particularly 
preparing  for  and  during  at-sea  testing. 

A-RCI  took  an  integrated  acoustic  system  that  was  difficult  and  time 
consuming  to  change  and  converted  it  into  a  federated  system  that  could  be 
upgraded  in  modules — that  is,  “plug  and  play.”  Such  an  approach  was  common  in 
the  private  sector  in  the  1990s  and  even  before.  Although  the  idea  wasn’t  new,  the 
application  of  this  approach  to  an  existing  warfighting  system  was  daunting.  As  a 
point  of  reference,  in  the  mid-1990s,  IBM  was  struggling  with  similar  arguments 
about  changing  the  way  it  did  business;  that  is,  should  IBM  stick  with  mainframe 
computers  running  proprietary  programs,  or  should  the  company  pursue  the 
integration  of  “best  of  breed”  software  solutions  that  could  interoperate  with 
competitors’  software  and  run  on  computers  manufactured  by  competitors  of  IBM? 
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Even  today,  there  are  arguments  within  the  DoD  about  whether  federated  systems 
are  a  sound  approach  for  warfighting  systems. 

Acoustic  Rapid  COTS  Insertion  progressed  at  a  seemingly  crushing  pace, 
with  software  changes  being  implemented  annually  and  hardware  changes 
biannually.  A-RCI  was  a  “poster  child”  for  evolutionary  acquisition — because  the 
endpoint  of  the  effort  was  not  clearly  defined,  but  there  was  a  recognized  need  for 
improvement. 

The  results  of  A-RCI  were  astounding  cost  reduction,  dramatic  improvement 
in  technical  performance,  successful  use  of  COTS  hardware  in  a  critical  warfighting 
application,  logistics  support  improvements,  and  an  acquisition  model  that  might 
have  broad  applicability  across  the  DoD. 

Together  with  A-RCI’s  amazing  results  came  a  series  of  questions  that  must 
be  considered. 

•  Was  A-RCI  a  one-time  success,  providing  a  model  that  could  not  be  re¬ 
applied  because  of  structural  impediments  within  the  DoD? 

•  Was  A-RCI  leadership  a  unique  alignment  of  extraordinary  people  that 
brought  about  change  but  is  unlikely  to  be  duplicated  for  future  systems? 

•  Is  the  DoD  acquisition  culture  so  rigid  that  it  will  stifle  and  kill  future  similar 
efforts? 

•  Will  cooperation  among  the  user  community  support  similar  efforts  in  the 
future? 

•  Are  there  such  operational  demands  on  the  user  community  that  they 
cannot  tolerate  the  tempo  of  change  that  delivers  new  software  or 
hardware  technology  annually  or  bi-annually? 

•  Is  modular  open  systems  architecture  scaleable  to  large  warfighting 
systems:  fire  control  or  command  and  control  systems,  for  example? 
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III.  Scope 


The  scope  of  this  research  effort  included  several  elements.  The  first  was  to 
interview  key  participants  in  A-RCI  and  to  gain  their  perspective  on  key  contributors 
to  the  success  of  A-RCI.  Persons  interviewed  were  asked  to  identify  what  they 
considered  the  unique  A-RCI  approaches  and  circumstances.  The  second  element 
included  literature  research  related  to  acquisition  processes  and  practices,  modular 
open  systems  approach  (MOSA)/open  architecture  (OA),  and  written  documentation 
related  to  A-RCI. 

A.  Definitions 

Definitions  of  Evolutionary  Acquisition,  Spiral  Acquisition,  Modular  Open 
Systems  Approach,  Open  Architecture  Implementation,  and  Acoustic  Rapid  COTS 
Insertion  provide  a  foundation  on  which  to  base  a  discussion  about  A-RCI. 

1.  Evolutionary  Acquisition: 

Evolutionary  acquisition  is  a  developmental  approach  to  achieve  useful 
increments  of  military  capability  without  having  to  delay  an  entire  acquisition  while 
awaiting  lagging  technology  or  awaiting  clarification  of  the  entire  required  end-state 
(objective  solution).  Evolutionary  acquisition  has  recently  become  the  preferred 
approach  to  satisfying  operational  needs,  in  an  attempt  to  shorten  acquisition  cycles 
and  place  needed  weapon  systems  into  the  hands  of  the  military  more  quickly  than 
in  the  past.^ 

2.  Spiral  Development: 

Spiral  Development  is  an  evolutionary  acquisition  process  used  when  a 
desired  capability  has  been  identified,  but  the  end-state  requirements  are  not  known 
at  program  initiation.  Requirements  are  refined  through  demonstration,  user 


^  Department  of  Defense,  Instruction,  Operation  of  the  Defense  Acquisition  System,  12  May  2003, 
DoDI  5000.2,  Paragraph  3.3. 
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feedback,  and  risk  management.  Each  “spiral”  provides  the  user  an  improved 
capability.^ 


3.  Modular  Open  Systems  Approach  (MOSA): 

Modular  Open  Systems  Approach  is  the  breaking  of  systems  or  systems  of 
systems  into  functional  components — hardware  and  software — and  then  designating 
and  controlling  the  key  interfaces,  standards,  and  protocols.  Open  standards  are 
incorporated  to  ensure  broadest  compatibility.  Conformance  with  these 
requirements  must  be  certified  by  developers.  MOSA  is  nurtured  in  an  enabling 
environment.  The  result  is  “plug  and  play”  components  that  can  be  separately 
updated  or  improved.'*  ®  MOSA  contains  five  elements  that  shape  its  technical  and 
business  strategies;  these  elements,  or  principles,  are  described  in  the  Program 
Manager’s  Guide:  A  Modular  Open  System  Approach  (MOSA)  to  Acquisition,  as 
follows.® 

Principle  1.  Establish  an  Enabling  Environment 

To  adhere  to  this  principle,  the  PM  must  establish  supportive  requirements, 
business  practices,  and  technology  development,  acquisition,  test  and 
evaluation,  and  product  support  strategies  needed  for  effective  development 
of  open  systems.  Assigning  responsibility  for  MOSA  implementation,  ensuring 
appropriate  experience  and  training  on  MOSA,  continuing  market  research, 
and  proactive  identification  and  overcoming  of  barriers  or  obstacles  that  can 
potentially  slow  down  or  even,  in  some  cases,  undermine  effective  MOSA 
implementation  are  among  the  supportive  practices  needed  for  creating  an 
enabling  MOSA  environment. 

Principle  2.  Employ  Modular  Design 


®  Ibid. 

Defense  Acquisition  University,  online  course:  Naval  Open  Architecture,  CLE012;  available  from 
https://learn.dau.mil/html/clc/Clc.isp;  accessed  2  August  2006. 

®  Rene  G.  Rendon,  Using  A  Modular  Open  Systems  Approach  In  Defense  Acquisitions:  Implications 
for  The  Contracting  Process,  Acquisition  Research  Sponsored  Report  Series,  NPS-AM-06-010 
(Monterey,  CA:  Naval  Postgraduate  School,  30  January  2006). 

®  Open  Systems  Joint  Task  Force,  Program  Manager’s  Guide:  A  Modular  Open  Systems  Approach 
(MOSA)  to  Acquisition,  Version  2.0  (Washington,  DC:  author,  September  2004). 
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Partitioning  a  system  appropriately  during  the  design  process  to  isolate 
functionality  makes  the  system  easier  to  develop,  maintain,  and  modify  or 
upgrade.  Given  a  system  designed  for  modularity,  functions  that  change 
rapidly  or  evolve  over  time  can  be  upgraded  and  changed  with  minor  impact 
to  the  remainder  of  the  system.  This  occurs  when  the  design  process  starts 
with  modularity  and  future  evolution  as  an  objective.  Modular  designs  are 
characterized  by  the  following: 


o  Functionally  partitioned  into  discrete,  scalable,  reusable 
modules  consisting  of  isolated,  self-contained  functional 
elements 

o  Rigorous  use  of  disciplined  definition  of  modular  interfaces,  to 
include  object-oriented  descriptions  of  module  functionality 
o  Designed  for  ease  of  change  to  achieve  technology 

transparency  and,  to  the  largest  extent  possible,  to  make  use  of 
commonly  used  industry  standards  for  key  interfaces 


Principle  3.  Designate  Key  Interfaces 

The  focus  of  MOSA  is  not  on  control  and  management  of  all  the  interfaces 
within  and  between  systems.  It  will  be  very  costly  and  perhaps  impractical  to 
manage  hundreds  and  in  some  cases  thousands  of  interfaces  used  within 
and  among  systems...  MOSA  manages  the  interfaces  by  grouping  them  into 
key  and  non-key  interfaces.  It  distinguishes  among  interfaces  that  are 
between  technologically  stable  and  volatile  modules,  between  highly  reliable 
and  more  frequently  failing  modules,  and  between  modules  with  least 
interoperability  impact  and  those  that  pass  vital  interoperability  information. 
Key  interfaces  should  utilize  open  standards  in  order  to  produce  the  largest 
lifecycle  cost  benefits. 


Principle  4.  Use  Open  Standards 

Interface  standards  specify  the  physical,  functional,  and  operational 
relationships  between  the  various  elements  (hardware  and  software),  to 
permit  interchangeability,  interconnection,  compatibility  and/or 
communication,  and  improve  logistics  support.  The  selection  of  the 
appropriate  standards  for  system  interfaces  should  be  based  on  sound 
market  research  of  available  standards  and  the  application  of  a  disciplined 
systems  engineering  process.  In  order  to  take  full  advantage  of  modularity  in 
design,  interface  standards  must  be  well  defined,  mature,  widely  used,  and 
readily  available.  In  general,  popular  open  standards  yield  the  most  benefit  to 
the  customer  in  terms  of  ease  of  future  changes  to  the  system  and  should  be 
the  standards  of  choice.  However,  there  are  situations  where  proprietary 
standards  are  the  correct  choice.  Standards  should  be  selected  based  on 
maturity,  market  acceptance,  and  allowance  for  future  technology  insertion. 
As  a  general  rule,  preference  is  given  to  the  use  of  open  interface  standards 
first,  the  de  facto  interface  standards  second,  and,  finally,  government  and 
proprietary  interface  standards.  Open  standards  allow  programs  to  leverage 
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commercially  funded  or  developed  technologies  and  to  take  advantage  of 
increased  competition.  They  also  allow  faster  upgrade  of  systems  with  less 
complexity  and  cost.  Bottom  line,  systems  can  be  fielded  that  are  more 
affordable. 

Principle  5.  Certify  conformance 

The  program  manager,  in  coordination  with  the  user,  should  prepare 
validation  and  verification  mechanisms  such  as  conformance  certification  and 
test  plans  to  ensure  that  the  system  and  its  component  modules  conform  to 
the  external  and  internal  open  interfaces — allowing  plug-and-play  of  modules, 
net-centric  information  exchange,  and  re-configuration  of  mission  capability  in 
response  to  new  threats  and  technologies.  Open  systems  verification  and 
validation  must  become  an  integral  part  of  the  overall  organization  change 
and  configuration  management  processes.  They  should  also  ensure  that  the 
system  components  and  selected  commercial  products  avoid  utilization  of 
vendor-unique  extensions  to  interface  standards  and  can  easily  be 
substituted  with  similar  components  from  competitive  sources. 


4.  Open  Architecture  Implementation: 

OPNAV  has  promulgated  five  OA  reinforcing  principles  to  support  MOSA.^ 

•  Modular  design  and  design  disclosure  to  permit  evolutionary  design, 
technology  insertion,  competitive  innovation,  and  alternative  competitive 
approaches  from  multiple  qualified  sources. 

•  Reusable  application  software,  selected  through  open  competition  of  “best 
of  breed”  candidates,  reviewed  by  subject  matter  expert  peers  and  based 
on  data-driven  analyses  and  experimentation  to  meet  operational 
requirements.  Design  disclosure  must  be  made  available  for  evolutionary 
improvement  to  all  qualified  sources. 

•  Interoperable  joint  warfiqhtinq  application  and  secure  information 
exchange  using  common  services  (e.g.,  OA  track  manager)  and 
information  assurance  as  intrinsic  design  elements. 

•  Lifecycle  affordability  including  system  design,  development,  delivery  and 
support  while  mitigating  COTS  obsolescence  by  exploiting  the  Rapid 


^  Deputy  Chief  of  Naval  Operations  (Warfare  Requirements  and  Programs)  (N6/N7),  Requirement  for 
Open  Architecture  (OA)  Implementation  (Washington,  DC:  author,  23  December  2005). 
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Capability  Insertion  Process/Advanced  Processor  [sic]  build  (RCIP/APB) 
methodology. 

•  Encouraging  competition  and  collaboration  through  alternative  solutions 
and  sources. 

5.  Acoustic  Rapid  COTS  Insertion  (A-RCI): 

A-RCI  is  the  spiral  acquisition  process  applied  to  naval  sonar  systems.  The 
approach  was  to  break  the  system  into  hardware  and  software  modules  and  then 
make  incremental  improvements  to  the  system  through  upgrading  the  various 
hardware  and  software  components.  Developers  were  tightly  linked  to  users,  and 
each  spiral  was  fully  demonstrated  prior  to  implementation. 
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IV 


Methodology 


A.  Expert  Interviews 

Development  of  this  case  study  required  discussions  with  persons  who  were 
intimately  familiar  with  the  A-RCI/APB  processes  and  techniques,  who  were  present 
as  the  A-RCI/APB  initiative  unfolded,  and  who  understood  the  factors  that 
contributed  to  its  success. 

B.  Literature  Research 

Published  information  was  used  to  document  A-RCI  outcomes,  gain 
additional  information  on  A-RCI/APB  techniques  and  processes,  and  also  to  provide 
comparative  background  information.  Information  collected  through  a  literature 
review  was  arranged  and  analyzed  to  gain  greater  understanding  of  the  A-RCI/APB 
experience. 

OSD  and  CJCS  Regulatory  Guidance.  There  is  a  body  of  mandatory  and 
discretionary  guidance  published  by  the  Office  of  the  Secretary  of  Defense,  the 
Chairman  of  the  Joint  Chiefs  of  Staff  and  by  the  DoD  Components.  Much  of  this 
material  is  on  the  AT&L  Knowledge  Sharing  System  website  maintained  by  the 
Defense  Acquisition  University  (DAU)  for  the  Under  Secretary  of  Defense 
(Acquisition,  Technology  and  Logistics),  USD  (AT&L).  The  site  provides  current 
web-based  materials  that  govern  defense  acquisition.  Defense  acquisition  policy 
and  processes  are  addressed  in  the  DoD  5000  series. 

Policy  and  practice  on  identification  and  documentation  of  user  capabilities 
are  addressed  in  the  CJCS  3170  series. 

1.  Other  Published  Materials: 

These  include  books,  journals,  periodicals.  Government  documents,  reports, 
best  practices,  theses,  studies,  speeches,  and  briefings.  Much  has  been  written  on 
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federated  systems,  Acoustic  Rapid  COTS  Insertion  (A-RCI),  Modular  Open  Systems 
Approach  (MOSA),  and  spiral  acquisition. 

The  Defense  Acquisition  University  has  developed  and  compiled  educational 
materials  on  spiral  development  and  MOSA  best  practices  and  has  placed 
significant  materials  online.  Naval  Open  Architecture  is  a  “Special  Interest  Area 
(SIA)”  on  the  DAU  Acquisition  Community  Connection  website.  This  SIA  site 
provides  Navy  Guidance  on  open  architecture  and  offers  useful  tools  and 
perspective,  much  of  it  derived  from  A-RCI/APB  experience.  The  site  provides  a  link 
to  a  self-paced  learning  module  on  Naval  Open  Architecture.  The  Naval  OA  SIA  is 
an  excellent  site  for  anyone  interested  in  using  a  modular  open  system  approach 
(MOSA)  to  hardware  and  software  development. 

In  addition  to  the  DAU  websites,  there  are  other  significant  materials  that  are 
web  accessible,  including  the  Open  Systems  Joint  Task  Force  website.® 

Finally,  considerable  associated  work  has  been  commissioned  by  the 
Program  Manager,  Naval  Open  Architecture,  Program  Executive  Office  for 
Integrated  Warfare  Systems  (PEO  IWS). 


®  Open  Systems  Joint  Task  Force,  http://www.acq.osd.mil/ositf/,  Department  of  Defense,  Accessed  28 
October  2006 
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V 


Data  and  Analysis 


A.  The  Crisis 

During  the  mid-1990s,  it  became  apparent  that  the  U.S.  Navy  had  lost  its 
acoustic  superiority  with  the  introduction  of  “quieting”  technologies  in  other  nations’ 
submarines.®  At  the  same  time,  the  Navy’s  priorities  did  not  support  funding  a  large 
developmental  effort  as  would  have  been  undertaken  during  the  Cold  War.  Not  only 
was  there  insufficient  funding,  there  was  not  time:  developmental  programs  for 
warfighting  systems  stretched  over  ten  or  more  years.  Improvement  in  the  Navy’s 
acoustic  capability  presented  an  immediate  need,  unsupported  by  necessary 
funding.  For  submariners,  this  indeed  was  a  crisis. 

B.  The  Strategy — Modular  Open  Systems  Approach 

Navy  developers  had  to  try  a  new  approach  in  response  to  their  crisis.  Their 
answer  was  a  modular  open  systems  approach.  Federated  systems  were  being 
developed  and  used  widely  in  the  private  sector,  but  such  an  approach  was  not  well 
understood  for  naval  warfighting  applications.  In  retrospect,  it  might  seem  that  the 
Navy  was  far  behind  commercial  practice,  but  IBM  was  struggling  through  similar 
difficulties  during  a  corporate  restructuring  at  roughly  the  same  time.  IBM’s  strategic 
decisions  were  wrapped  around  some  of  the  same  concerns  as  A-RCI — the  need  to 
tap  innovative,  cost-efficient  software  applications  sought  by  IBM’s  customers,  the 
need  for  software  called  “middleware”  that  applications  could  link  to,  and  portability 
that  would  allow  the  software  to  be  successfully  operated  on  different  hardware 
platforms.^® 


®  Richard  Scott,  “Open  for  Business:  a  New  Model  for  Submarine  Sonar,”  Jane’s  Navy  International,  1 
March  2006. 

Louis  V.  Gerstner,  Jr.,  Who  Says  Elephants  Can’t  Dance:  Leading  a  Great  Enterprise  Through 
Dramatic  Change  (New  York:  HarperCollins  Publishers,  2003). 


-13- 


As  noted  above,  A-RCI  was  a  response  to  a  difficult  situation  at  a  time  when 
other  entities  were  wrestling  with  similar  problems;  however,  that  does  not  provide  a 
sufficient  rationale  for  writing  a  case  study.  The  A-RCI  case  study  is  worth  relating 
because  of  the  creative  approaches  taken  by  the  submarine  community.  The  path 
that  A-RCI  took  was  multifaceted,  and  the  approaches  used  are  instructive  for  others 
considering  MOSA.  The  A-RCI  effort  was  also  daunting  and,  in  many  ways, 
inspiring. 


Modular  Open  Systems  Approach 

(MOSA) 


Vision  Principles  Benefits 


MOSA  is  an 
inle};ral  part  of  all 
acquisition  slralc'f'ios  to 
achieve  affordable, 
evolutionary, 
and  joint  combat 
capability 


sldblish  Enabling  Environment 


Employ  Modular  Des/gn 


Designate  Key  Interfaces 


Select  Open  Standards 


Certify  Conformance 


•/  Ease  of  Change 

Reducc'd  Total  Ownership  Cost 

Reduced  Cycle-Time 

>/  Enabling  Joint  Integrated 

Architectures  and  Interoperability 

•/  Risk  Mitigation 


Indicators 


Figure  2.  Modular  Open  Systems  Approach  (MOSA)^^ 

Legacy  Systems  such  as  an  existing  submarine  sonar  system  circa  1990 
were  not  modular  in  their  design.  Therefore,  the  early  A-RCI  effort  required 
modularizing  the  sonar  systems.  It  is  important  to  note  that  upgrade  of  a  legacy 
system  today  might  first  require  a  business  case  analysis  of  whether  modularization 


'''  Open  Systems  Joint  Task  Force,  Program  Manager’s  Guide:  A  Modular  Open  System  Approach 
(MOSA)  to  Acquisition,  Version  2.0  (Washington,  DC:  author,  September  2004),  3. 
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is  feasible  and  the  best  approach.  For  example,  it  might  not  make  business  sense 
to  modularize  a  system  whose  replacement  is  entering  its  production  and 
deployment  phase. 

It  was  necessary,  then,  that  the  operational  community  (i.e.,  submarine 
operators)  accept  operational  limitations  while  the  system  was  being  modularized. 

In  modularization  of  A-RCI,  it  was  necessary  in  the  first  APB  for  the  user  temporarily 
to  accept  an  operational  compromise  (limiting  the  towed  array  sonar  to  a  single 
display  station)  rather  than  to  retain  the  freedom  to  use  any  of  the  several  onboard 
displays  for  towed-array  sonar  or  any  of  the  other  sonar  systems. 

A-RCI’s  pursuance  of  modularity  led  to  separation  of  hardware  and  software 
for  purposes  of  system  improvement.  In  this  way,  processors  (the  hardware)  could 
be  commercial-off-the-shelf  (COTS)  and  could  be  upgraded  in  consonance  with  the 
evolving  commercial  market.  The  application  software  could  be  developed 
separately  from  the  processors  as  long  as  the  two  would  interoperate  through  use  of 
transportable  middleware.  The  transportable  middleware  provided  freedom  to  run 
application  software  on  different  processors.  All  this  was  made  possible  through  the 
control  of  key  interfaces. 

System  modularity  enabled  acquisition  speed  and  focus,  facilitating  change  to 
parts  of  the  system  where  necessary,  while  leaving  other  components  undisturbed. 
Although  this  aspect  might  sound  almost  trivial,  modular  systems  are  very  different 
from  fully  integrated  systems,  in  which  small  software  changes  may  have  major 
unexpected  consequences  in  functions  that  are  seemingly  unrelated  to  the  change. 

A  requirement  of  MOSA  is  that  the  key  interfaces  must  be  carefully  controlled. 
Although  not  trivial,  the  control  of  key  interfaces  is  much  easier  than  trying  to 
understand  and  control  a// the  internal  interfaces  within  a  large,  fully  integrated 
system.  This  is  especially  applicable  when  integrating  COTS  components  where 
some  interfaces  are  not  accessible  and,  therefore,  not  controllable. 
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The  A-RCI  developmental  process  included  a  Build/Test/Build  sequence.  For 
A-RCI,  the  developmental  processes  required  a  thorough  demonstration  of  new 
technical  capabilities  to  verify  system  improvement.  New  system  capabilities  were 
compared  to  previous  system  capabilities.  Additionally,  new  competing  systems 
were  compared  one  against  another.  A-RCI  was  able  to  demonstrate  system 
upgrades  through  the  use  of  recorded  operational  events.  In  this  way,  competing 
systems  could  be  judged  on  their  ability  to  process  and  display  real  data  recorded 
during  actual  operational  events.  Competing  systems  could  be  peer  reviewed  both 
realistically  and  “on  a  level  playing  field,”  a  situation  that  permitted  competitive 
solutions  to  be  judged  solely  on  their  merit. 

1.  MOSA  Business  Strategy: 

A-RCI  evolutionary  strategy  was  that  software  changes  would  be 
accomplished  annt/a//y  through  a  developmental  effort  called  Advanced  Processing 
Builds  (APBs),  while  COTS  processors  (the  hardware)  would  be  selected  bi- 
annually.  This  was  a  highly  demanding  acquisition  “op  tempo.” 

MOSA  encourages  materiel  developers  to  broaden  communication  links  with 
users,  contractors,  and  research  labs  in  order  to  orchestrate  both  a  competitive  and 
collaborative  effort. 

The  competitive  “playing  field”  had  to  be  set  up  to  attract  innovative 
contractors  who  might  be  new  to  DoD  contracting  or  might  be  intimidated  by  large 
prime  contractors.  Competition  had  to  focus  on  best  ideas  and  best  performance, 
not  on  politics  and  not  on  a  preordained  hierarchy  of  competitors — that  is,  a 
competitive  and  level  playing  field  where  the  best  technical  solutions  would  “win.” 

Intellectual  Property  rights  had  to  be  respected,  while  at  the  same  time,  data 
and  design  information  needed  to  be  shared  through  mechanisms  that  were 
perceived  as  fair  to  competitors.  A-RCI/APB  processes  and  structures  were  required 
to  facilitate  the  competitive,  collaborative  environment.  Intellectual  property  rights 
and  the  protection  of  proprietary  data  were  addressed  and  controlled  within  the 
terms  and  conditions  of  the  contract.  These  legal  issues  had  to  be  worked  out  “on 
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the  fly”  during  the  A-RCI/APB  effort.  Today,  as  a  result  of  A-RCI  and  other  MOSA 
efforts,  there  is  helpful  guidance  that  can  be  used  in  constructing  contracts.  The 
Naval  Open  Architecture  Contract  Guidebook,  Version  1,  was  published  7  July  2006, 
and  provides  suggested  language  that  may  be  included  in  Sections  C  (i.e.,  in  the 
Statement  of  Work),  L,  (Instructions  to  Offerors  in  the  RFP)  and  M  (Evaluation 
Factors  in  the  RFP).^^  For  the  reader  not  familiar  with  contracting,  the  RFP  is  a 
document  typically  used  by  Government  contracting  activities,  inviting  potential 
contractors  to  compete  for  work  by  submitting  their  proposals.  The  RFP  and  the 
contract  itself  are  arranged  in  accordance  with  the  uniform  contract  format,  which  is 
described  in  the  Federal  Acquisition  Regulation  (FAR). 

The  A-RCI  experience  illustrated  that  open  code  and  sharing  of  code  enabled 
collaboration  and  enhanced  the  success  of  open  systems  design.  However, 
intellectual  property  rights  and  proprietary  information  must  be  respected.  Several 
practitioners  associated  with  A-RCI/APB  have  made  the  point  that  intellectual 
property  rights  to  portions  of  a  warfighting  system  can  hold  the  system  hostage  and 
prevent  its  continued  improvement  or  reuse.  Prevailing  thinking  was  that  intellectual 
property  rights  should  be  made  available  as  part  of  the  price  of  entering  into  the 
competition.  In  that  way,  code  and  design  information  could  be  shared  with  other 
participants  to  maximize  progress.  This  thinking  is  consistent  with  the  NOA  Contract 
Guidebook,  which  states,  “The  U.S.  Government’s  (hereinafter  “Government”)  ability 
to  acquire  at  least  Government  Purpose  Rights  (GPR)  to  data  and  intellectual 
property  and  to  minimize  proprietary  elements  to  the  lowest  component  level  is 
critical  to  this  effort.”^® 

Each  development  “spiral”  contained  a  highly  competitive  demonstration 
period,  but  collaboration  and  information  sharing  were  expected.  In  A-RCI/APB,  the 
collaboration  was  characterized  as  “winning  together.” 


Program  Executive  Officer,  Integrated  Warfare  Systems  7,  Naval  Open  Architecture  Contract 
Guidebook,  Version  1  (Washington,  DC:  author,  7  July  2006). 

Ibid.,  3. 
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All  A-RCI  participants  had  to  be  acutely  attuned  to  the  schedule.  If 
competitors  were  unable  to  stay  on  schedule,  they  had  to  be  left  behind  for  that 
spiral.  Rigorous  adherence  to  schedule — schedule  discipline — was  a  necessity  to 
meet  promised  customer  delivery  dates. 

C.  Changing  the  Culture 

In  reaching  out  to  small  innovative  contractors,  large  contractors,  academic 
labs,  and  Government  activities,  it  was  necessary  in  the  case  of  A-RCI  to  change  the 
nature  of  the  “prime  contractor.”  Retention  of  the  prime  contractor  relationship  would 
have  been  “business  as  usual”  and  not  conducive  to  the  participation  by  small 
innovative  contractors  and  other  non-traditional  players.  The  outcome  was  that  the 
prime  contractor  was  removed  from  the  source  selection  process  and  became  the 
“prime  system  integrator.”  The  competing  solutions  were  demonstrated  using  real- 
world  recorded  sensor  input,  and  the  best  solutions  were  selected  through  “peer 
review,”  which  is  further  described  below.  A-RCI  and  APB  upgrades — COTS 
processors  and  improved  software  algorithms — that  successfully  emerged  from 
Build/Test/Build  were  handed  over  to  the  prime  system  integrator  for  integration  and 
installation  aboard  submarines. 


APB  Keys  to  Success 


tNo  Oue  Org.iuizatiou  has  the  Whole  Story 
•  SDWG  member',  are  experts  m  their  field 
*  Organizational  boundaries  and  biases  are  mimmized 

tData  Driven  Testing  (“Builtl-Test-Builtl'*) 

*  Use  actual  recorded  sea  data  (including  targets  of  interest) 

*  Prove  algorithms  on  real  world  data  while  still  m  de\'elopment 

t  Significant  Fleet  Involvement 

•  Fleet  members  on  SDWG  and  associated  working  groups 
•  Allows  rapid  feedback  mto  development  process 


tPeer  Review  of  New  Developments 
•  Tap  expertise  of  all  organizations  early  in  cycle 
•  Ensure  only  the  "Best  of  the  Best”  goes  forward 

t  Verify  Algorithms  Prior  to  Implementation 

•  Perform  modeling  of  new  algorithms  usmg  several  environments 
•  Generate  “Consumer  Reports"  to  document  predicted  performance 

t  Continuing  Assessments  and  Measurements 
•  Measure  transition  effectiveness 
•  Identify  Improvement  Areas 


Figure  3.  Advanced  Processing  Build  Keys  to  Success^^ 


Sonar  Development  Working  Group  (SDWG),  1998-99  Year  in  Review  (Washington,  DC:  author, 
15  September  1999),  5. 
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Peer  Review  of  New  Developments  is  recognized  within  the  A-RCI/APB 
program  as  being  one  of  the  primary  reasons  for  success  (See  Figure  3,  above). 

The  Navy  took  a  page  out  of  academia  and  adapted  it  to  ensure  a  fair  playing  field 
for  competitors  that  would  ensure  selection  of  the  best  alternatives  for  further 
development.  Peer  review  of  Advance  Processing  Builds  (APB)  was  conducted 
under  the  oversight  of  a  Navy  Program  Manager  and  trusted  advisors.  Oversight  of 
Peer  Review  is  uniquely  challenging  and,  at  least  in  the  A-RCI/APB  experience,  the 
PM  needed  the  following  characteristics  to  be  successful. 

1.  Technically  Competent 

Able  to  understand  and  work  through  the  relevant  technical  issues. 

2.  Proactive 

Involved  in  the  process  and  focused  on  performance  and  product  delivery. 
Able  to  work  in  a  competitive  environment  with  multi-organizational  intrigues 
while  participants  jockeyed  for  position. 

3.  Disciplined/Structured 

Willing  to  enforce  professional  and  disciplined  interaction  among 
organizational  entities  to  achieve  an  orderly  and  functional  process. 

The  peers  included  fleet  (user)  representatives,  algorithm  developers,  and 
evaluators.  The  program  office,  together  with  trusted  advisors,  selected  persons 
with  professional  reputations  for  individual  excellence,  coupled  with  demonstrated 
ability  to  place  Navy  interests  above  organizational  agendas.  Peer  appointment  was 
announced  by  e-mail  and  in  meetings.  The  announcements  were  made  with 
sufficient  formality  or  gravity  that  selection  of  peers  was  treated  seriously,  and  such 
an  appointment  was  sought  after. 

1.  Peer  duration  varied 

In  some  cases,  peers  have  served  from  1997  through  the  present  (2006).  In 
other  cases,  peer  duration  was  a  year  or  two.  Fleet  representatives  typically 
have  served  until  their  change  of  assignment — generally  one  or  two  years. 
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2.  Peer  funding  differed  according  to  circumstances 

Participants  were  funded  by  one  or  more  of  the  participating  program  offices 
for  the  time  they  spent  on  the  peer  group.  This  varied  from  %-time  for 
meeting  attendance  and  advice  to  full-time  for  peer  group  members  who 
planned  and  conducted  evaluations. 

3.  Peer  group  structure  designed  for  flexibility 

Different  peer  working  groups  were  established.  Two  examples  are  the 
Automation  Working  Group  and  the  Signal  Processing  Working  Group  (See 
1998-99  Peer  Working  Groups  at  the  right  side  of  Figure  4,  below.)  Over 
time,  the  peer  working  group  structure  evolved  as  needs  dictated.  In  some 
cases  working  groups  merged;  in  other  cases,  groups  disbanded  when  their 
work  was  completed. 
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Figure  4.  Sonar  Development  Working  Group^^ 


Sonar  Development  Working  Group  (SDWG),  1998-99  Year  in  Review,  (Washington,  DC:  author, 
15  September  1999),  5. 
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1.  Documentation: 

A  partial  list  of  peer  group  documentation,  which  guided  the  peer  groups  and 
reported  their  progress,  is  provided  for  illustrative  purposes  as  follows: 

•  Advanced  Processing  Build  Instruction,  circa  2000. 

•  Briefings  (in  viewgraph  format)  for  new  developers,  summarizing  “rules  of 
the  road.” 

•  Year  in  Review  reports. 

•  “Snapshots”  of  metrics. 

•  Peer  group  evaluation  reports  as  APBs  progressed  through  Steps  1-4. 

•  Memoranda  of  Understanding  of  among  various  stakeholders. 

•  Checklists  to  guide  algorithm  developers  through  the  approval  process. 

•  Descriptions  of  open  and  closed  data  sets,  against  which  the  APBs  would 
be  tested. 

Other  Peer  Group  documentation  includes  the  following  outside  studies. 

•  Air  Force  COTS  study  that  reviewed  A-RCI. 

•  NDIA  Study  of  APB/A-RCI. 

2.  Systems  Engineering: 

In  the  case  of  A-RCI/APB,  a  Systems  Engineering  Process  (SEP)  and 
structure  were  needed  for  guiding  and  synchronizing  the  work  of  the  various  players, 
accommodating  a  comp/ex  testing  regimen,  carefully  controlling  key  interfaces,  and 
incorporating  standards  to  enable  interoperability  of  hardware  and  software.  During 
development,  software  took  shape  under  the  direction  of  the  NAVSEA’s  Advanced 
Systems  Technology  Office  (ASTO).  Software  development  was  accomplished  by 
small  innovative  contractors,  academic  research  labs,  and  Government  labs 
participating  competitively  and  collaboratively.  But  these  entities  were  not,  as  yet, 
organized  under  a  prime  contractor.  Later  in  the  process,  software  development 
was  consolidated  under  the  direction  of  a  software  APB  integrator.  Following  a  cycle 
of  Build/Test/Build,  hardware  and  software  systems  and  components  were  handed- 
off  to  the  prime  system  integrator  for  assembly  of  the  upgrade  package  and 
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installation  onto  submarines.  All  of  this  occurred  at  a  rapid  op  tempo.  As  may  be 
envisioned,  no  single  contractor  was  perfectly  positioned  to  accomplish  SEP  from 
beginning-to-end — as  a  prime  contractor  would  have  done  in  a  traditional 
development.  Beyond  the  question  of  who  should  be  responsible  for  the  Systems 
Engineering  Process,  end-to-end,  over  the  entire  developmental  cycle,  spiral 
development  required  repetitive  developmental  cycles — further  complicating 
management  of  the  SEP. 


COTS  Hardware 


I  I  Many  Providers 

' - '  //^KID  Cm^ll  Diiftlm. 


Procurement  -  Packaging 

(Many  providers) 


(ONR,  Small  Business, 
Academia,  Industry) 


Figure  5.  System  Development  ModeF^ 


A-RCI  systems  engineering  was  led  by  the  Navy’s  PMS  425  using  an  IPT 
arrangement.  (See  the  process  depiction  in  Figure  5,  above.)  Typically,  the 
applicable  warfare  center  would  have  been  the  Systems  Engineering  Technical 


C.  E.  Barron,  “Naval  Open  Architecture  Acquisition  Approach  (Draft):  A  Proven  Acquisition  Model 
for  a  National  Security  Systems  Acquisition  in  an  Environment  Dominated  by  Commercial  Off  the 
Shelf  Technologies”  (Draft,  August  2006),  15. 
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Authority  (or  Technical  Design  Agent  as  it  was  called  at  the  time).  But,  in  this 
situation,  NUWC,  the  applicable  Warfare  Center,  was  a  competitor  in  the  Advanced 
Processing  Build  and  could  not  perform  both  functions  without  at  least  the 
perception  of  “tipping”  the  playing  field  in  their  own  favor.  Responsibility  for 
managing  the  A-RCI/APB  Systems  Engineering  Process  eventually  would  be 
handed  off  to  the  prime  system  integrator,  Lockheed  Martin;  LM  participated, 
therefore,  as  an  important  stakeholder  throughout  the  SE  IPT.  Once  again,  prior  to 
final  integration,  Lockheed  Martin  could  not  manage  the  SEP  without  risk  to  the 
competitive  level  playing  field;  but,  they  needed  to  be  involved  to  help  insure  a 
smooth  transition  during  system  integration  and  installation.  For  future  programs, 
SEP  responsibility  might  reside  with  the  Government  materiel  developer  (or  be 
separately  contracted)  during  testing  and  Peer  Review  before  being  handed  off  to  a 
prime  system  integrator.  Needless  to  say,  SEP  management  is  potentially  a  serious 
risk  area.  On  one  side  of  the  balance,  the  Government  PM  office  might  not  have  the 
necessary  staffing  for  managing  SEP;  on  the  other  side,  contracting  out  SEP  might 
damage  the  necessary  sense  of  trust  and  confidence  in  a  competitive  level  playing 
field. 
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The  4-STEP  Process  At  A  Glance 
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Figure  6.  The  4-Step  Process^^ 


3.  The  4-Step  Process: 

The  rapid  op-tempo  of  annual  Advanced  Processing  Builds  (APBs)  was 
accomplished  through  a  4-Step  Process,  shown  in  Figure  6,  above.  Further 
description  of  the  4-Step  Process  is  extracted  from  the  SDWG  1998-99  Year  in 
Review  Report  to  clarify  the  process^®: 

Step1.  Algorithm  Survey: 

Step  1  is  a  survey  of  promising  algorithms  from  the  R&D  community  including 
6.2  and  6.3  activities,  Office  of  Naval  Research  (ONR),  Defense  Advanced 
Research  Projects  Agency  (DARPA),  Industry  Independent  Research  and 


John  Stapleton,  Briefing:  “APB/A-RCI  Performance  Driven  Acquisition  Reform  for  Undersea 
Warfare  Superiority,”  26  September  2006,  Slide  2. 

Sonar  Development  Working  Group  (SDWG),  1998-99  Year  in  Review,  (Washington,  DC:  author, 
15  September  1999),  3-4. 
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Development  (IR&D),  Broad  Area  Announcements  (BAA’s)  and  related  Navy 
programs  such  as  the  Submarine  Security  Program  and  the  Integrated 
Undersea  Surveillance  System  (lUSS)  community.  The  goal  of  Step  1  is  to 
consider  algorithms  developed  on  other  Navy  funds  and  to  determine  their 
tactical  importance,  maturity,  expected  performance  and  computational 
resource  requirement. 

Step  2.  Algorithm  Testing: 

Step  2  is  a  test  of  relatively  mature  algorithms  that  promise  to  provide 
performance  improvements  to  the  fleet.  They  transition  to  Step  3  based  on 
tested  performance  using  common  data  sets  and  common  metrics  developed 
by  a  working  group  of  technical  principals  in  conjunction  with  the  developers 
and  fleet  representatives.  Utilizing  real  world  data  sets  collected  from  U.S. 
submarine  exercises  and  provided  by  the  Office  of  Naval  Intelligence  (ONI), 
this  testing  provides  a  projection  of  algorithm  performance  using  real  world 
ocean  noise  and  target  signatures  of  interest.  Experience  has  shown  that 
testing  on  synthetic  data  does  little  to  uncover  problems  or  project 
performance  for  sonar  algorithms  in  fleet  use.  The  APB  Step  2  process  is 
unique  in  that  developers  submit  algorithms  for  testing  with  the  expectation  of 
useful  feedback  from  the  testing  process.  Algorithm  promotion  to  Step  3  is 
based  on  acceptable  performance  as  determined  by  the  cognizant  Peer 
Review  group. 

Step  3.  String  Testing: 

Algorithms  that  demonstrate  acceptable  performance  during  Step  2  testing 
are  passed  to  an  integration  agent  for  incorporation  into  an  end-to-end  sonar 
processing  string  on  the  IDP  Multipurpose  Processor  (MPP)  baseline.  This 
processing  string  is  called  an  APB.  The  Step  3  test,  conducted  by  the  Test, 
Evaluation  and  Assessment  Support  Group  (TEASG)  arm  of  the  SDWG, 
[Groups  descriptions  are  provided  at  Appendix  2.]  provides  an  opportunity  to 
independently  test  the  APB  string  for  compliance  with  performance 
requirements  as  well  as  fidelity  with  Step  2  performance  results.  It  also  serves 
to  introduce  fleet  representatives  to  the  new  features  in  a  string  context  and 
provide  for  fleet  feedback.  Similar  to  Step  2,  real  world  data  sets  are  used  for 
this  testing.  Any  identified  issues  resulting  from  the  Step  3  testing  are  then 
forwarded  to  the  integration  agent  for  resolution  prior  to  at-sea  testing. 
Independent  testing  of  the  APB  product  is  a  critical  step  in  the  build-test-build 
process.  It  ensures  readiness  for  at-sea  testing  and  provides  confidence  to 
the  community  contributors  that  their  ideas  have  been  implemented  properly. 

Step  4.  At-Sea  Testing: 

Step  4  is  the  at-sea  test  for  APB,  again  conducted  by  the  TEASG.  This  is  the 
most  important  phase  of  testing  the  algorithms  prior  to  inclusion  in  the  IDP 
baseline  and  provides  information  on  how  the  fleet  sonar  team  interacts  with 
the  APB  in  time  for  enhancement  or  corrective  action.  The  test  provides  the 
opportunity  to  verify  APB  algorithmic  performance  and  collect  calibrated  data 
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for  future  use.  The  TEASG  is  also  responsible  for  the  evaluation  and 
assessment  of  the  test  results  as  well  as  interpretation  of  algorithm  and 
system-level  results.  (NOTE:  The  at-sea  test  conducted  by  the  TEASG  is  not 
intended  to  serve  as  system  certification.  System  certification  is  accomplished 
by  the  cognizant  program  office  via  separate  testing  after  full  integration  of  the 
APB  into  the  baseline  system.) 

At  the  completion  of  Step-4  testing,  the  APB  is  delivered  to  the  program  office 
for  integration  into  the  baseline  system.  To  assist  in  the  successful  transition  of  APB 
improvements,  a  Systems  Engineering  Working  Group  is  established  during  Step  3 
of  the  process  (and  continues  through  Step  4).  This  group  ensures  that  issues 
related  to  the  APB  integration  into  the  baseline  sonar  system  are  resolved  as  early 
as  possible  in  the  development  cycle  and  that  systems-level  requirements  are 
factored  into  the  APB  product.  In  Step  3,  the  group  also  initiates  development  of  any 
required  program  office  documentation  such  as  specifications  and  change  proposals 
to  ensure  the  baseline  system  can  readily  incorporate  the  APB  product. 

The  APB  and  IDP  partnership  (via  ARCI  introduction)  have  demonstrated  that 
the  Navy  can  affordably  develop  advanced  acoustic  processing  capabilities  and 
annually  transition  these  new  capabilities  to  submarine  platforms  in  quantity. 

4.  User  Participation: 

Involvement  and  stakeholder  buy-in  were  major  contributors  to  focusing  and 
speeding  the  A-RCI/APB  processes.  The  Submarine  Tactical  Requirements  Group 
(STRG)  set  A-RCI/APB  requirements  that  initiated  each  spiral.  Beyond  that,  user 
groups  provided  feedback  in  such  areas  as  ease  of  operation,  suitability  of 
configuration,  required  training,  and  supportability,  for  example.  Users,  of  course, 
were  heavily  involved  in  at-sea  testing  and  during  submarine  retrofit  periods. 
Additionally,  A-RCI  user  participants  served  as  a  communication  link  between 
developers  and  fleet  users.  The  ensuing  dialogue  contributed  substantially  to  sailor 
acceptance  of  A-RCI/APB  in  the  fleet. 

Communications  Forums.  Participation  in  essential  dialogue  involved  many 
different  forums  and  extended  through  each  developmental  sequence  and  into  the 
next.  The  importance  of  dialogue  between  users,  materiel  developers,  and 
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contractors  cannot  be  overemphasized.  To  provide  a  glimpse  into  the  intensity  of 
communication,  the  different  integrated  groups  that  assisted  A-RCI/APB  are 
described  in  Appendix  2,  extracted  from  Chapter  2  of  the  Sonar  Development 
Working  Group  (SDWG)  1998-1999  Year  in  Review  report.''^ 

In  summary,  at  least  six  facets  combined  to  make  the  A-RCI  culture  change 
revolutionary  within  the  DoD.  First  was  changing  the  nature  of  the  prime  contractor 
to  a  prime  system  integrator.  Second  was  gaining  the  participation  of  non-traditional 
technical  participants  who  brought  fresh,  innovative  ideas.  Third  was  the  peer 
review  process  which  leveled  the  competitive  playing  field,  allowing  good  ideas  to 
freely  compete.  Fourth  was  the  op  tempo  of  the  spirals — annual  software  Advanced 
Processing  Builds  and  bi-annual  processor  refreshment.  Fifth  was  the  intimate  user 
participation.  Sixth  was  the  intricate  communications  structure  that  supported  A- 
RCI/APB.  In  the  aggregate,  this  effort  took  heroic  commitment  by  many  different 
parties  who  historically  were  not  “friendly”  or  cooperative.  How  could  this  cultural 
change  be  catalyzed?  Part  of  the  answer  lay  in  process  and  contractual 
mechanisms.  Part  also  resulted  from  leadership,  which  is  discussed  below. 

D.  Leadership 

Strong  leadership  is  essential  to  proactive  change.  Several  of  the  A-RCI 
leadership  aspects  are  as  described  below. 

Mandate.  Senior  leaders  provide  pressure  to  change.  Without  this  “forcing 
function,”  it  is  difficult  for  mid-level  leaders/managers  to  achieve  major  change.  In 
the  case  of  A-RCI,  senior  leaders  told  the  acoustic  systems  office  to  “make 
something  happen.”  At  the  same  time,  senior  leadership  provided  top-cover — 
protection  from  above — and  empowered  people  to  innovate.  There  were 
undoubtedly  elements  of  positive  and  negative  motivation;  participants  both  wanted 
to  effect  change  and  also  had  the  sense  that  if  they  could  not  get  the  job  done,  they 
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would  be  replaced.  The  “mandate”  has  to  be  balanced — in  the  case  of  A-RCI,  senior 
leaders  upheld  such  balance  extraordinarily  well,  judging  by  the  outcome. 

Mid-level  Leadership.  A-RCI  appeared  to  have  excellent  leaders  in  various 
positions  who  accepted  the  challenge  and  effected  change.  Several  of  the  A-RCI 
stakeholders  interviewed  clearly  saw  themselves  as  empowered  agents  of  change', 
they  expanded  “the  vision,”  were  not  timid  about  making  decisions,  did  not  allow 
themselves  to  be  defeated  by  bureaucratic  obstacles,  and  motivated  others  to  act.  It 
is  quite  apparent  with  A-RCI  that  senior  leadership  vision  required  capable  leaders 
at  different  levels  and  in  different  organizations  to  “take  charge.”  This  is  what  led  to 
A-RCI’s  success. 

Mr.  Bill  Johnson,  deputy  program  manager,  PMS  425B,  Submarine  Combat 
Systems,  outlined  specific  leadership  actions  along  the  following  lines:^° 

•  Set  and  maintain  the  vision.  Keep  it  simple  and  consistent. 

•  Develop  a  strategy  to  implement  the  vision.  The  A-RCI  strategy 
incorporated  a  mixture  of  management,  technical,  and  business  aspects. 

•  Develop  and  cultivate  allies  at  all  levels.  A-RCI  included  industry. 
Congressional  members,  senior  leadership,  a  broad  array  of  stakeholders 
within  the  developmental  community,  and  fleet  users. 

•  Instill  within  the  team  a  sense  of  empowerment  and  entrepreneurial  spirit. 
A-RCI  encouraged  members  of  their  team  to  think  and  act  like  leaders. 

•  Set  the  expectations  for  excellence  and  the  operational  pace.  The  A-RCI 
leadership  team  established  aggressive  goals,  supported  by  rigorous 
processes  that  paced  the  developmental  effort. 

In  the  aggregate,  A-RCI  worked  because  stakeholders,  “formed  a  community 
that  learned  to  be  comfortable  with  change — not  just  technical  things  or  even 
business  processes.  The  real  change  involved  learning  to  work  with  new  people 
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from  places  we’d  never  dealt  with  before. This  is  a  reflection  of  a  new  leadership 
vision  that  was  widely  embraced  by  A-RCI  participants. 

E.  User  Participation 

Participation  and  buy-in  were  major  contributors  to  focusing  and  speeding  the 
process.  The  Submarine  Tactical  Requirements  Group  (STRG)  was  the  user  group 
that  identified  the  required  capability  to  be  developed  during  each  spiral.  This 
activity  provided  user  focus  to  A-RCI.  The  work  of  the  STRG  was  very  important  to 
the  user/developer  dialogue;  it  set  priorities  and  described  to  the  developer 
community  the  relevant  functional  “shortfalls”  or  “opportunities.” 

Just  as  with  other  programs,  there  were  many  “voices”  of  the  user.  A  group 
of  Senior  and  Master  Chiefs  provided  invaluable  human  system  integration  (HSI) 
insights.  Their  work  provided  feedback  on  APBs,  processors,  and  displays.  They 
also  challenged  sonar  training  by  testing  the  competency  of  sonar  technicians;  this 
testing  led  to  enhanced  training  that  improved  the  detection  skills  of  these 
technicians.  The  Senior  and  Master  Chiefs  thoroughly  bought-in  to  A-RCI/APB 
improvements;  for  the  first  time,  they  could  identify  shortfalls  and  see  resultant 
improvement  by  their  next  at-sea  deployment.  The  Chiefs  played  an  important  role 
in  getting  the  fleet  to  support  sonar  upgrades.  They  generated  excitement  in  the 
fleet  because  system  improvements  could  now  arrive  in  time  to  be  used  by  the 
sailors  who  had  helped  articulate  and  describe  the  needed  improvements. 

Operational  users  were  heavily  involved  in  at-sea  testing  and  during 
submarine  retrofit  periods.  This  demanded  system  upgrade  time,  training  time,  and 
operator  feedback. 

Support  of  A-RCI  may  have  pushed  some  within  the  user  community  well 
beyond  their  comfort  zone.  For  example,  modifications  to  training  packages  were 
very  demanding,  for  trainers  and  students  alike.  Additionally,  upgrades  in  hardware 
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and  software  placed  extra  burdens  on  submarine  crews  while  in  port.  At-sea  testing 
of  APBs  and  COTS  hardware  undoubtedly  placed  additional  workload  on  submarine 
crews. 


F.  Measurable  Effects 

1.  Technical  Performance: 

Within  eighteen  months,  A-RCI  had  provided  a  7-fold  increase  in  processing 
capability.  New  algorithms  provided  clearer  sonar  information  over  longer 
engagement  duration. 

•  Mean  operator  success  rate  increased  by  a  factor  of  4. 

•  Mean  number  of  false  alarm  reduced  by  40%. 

•  Detection  and  classification  time  improved  by  27  minutes. 

•  Mean  hold  time  improved  by  25  minutes. 
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Figure  7.  Performance  Improvement  Trend^^ 


2.  Reduced  Lifecycle  Cost 

The  Navy  is  currently  valictating  a  historical  cost  comparison  of  A-RCI  anct  its 
prectecessor  system.  Preliminary  results  compilect  from  10  years  of  data  on  both  A- 
RCI  and  its  predecessor  indicate  that  lifecycle  cost  has  improved  by  nearly  5:1 .  This 
comparison  includes  development,  production,  and  maintenance  costs. 


3.  Cost  Avoidance 

A-RCI  provided  many  examples  of  cost  savings/cost  avoidance. 

a.  Processor  Cost 

Processing  cost  was  reduced  by  a  factor  of  60,  that  is,  1/60*^  the  previous 
processing  cost  which  had  resulted  from  specially  developed  processors. 
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b.  Cost  of  Obsolescence 

Although  not  quantified,  there  were  two  aspects  to  ARCI’s  obsolescence 
costs.  First  was  use  of  upgrade  to  avoid  paying  the  high  cost  required  to 
provide  outdated,  scarce  components.  Second  was  harvesting  obsolete 
components  that  had  been  removed  from  upgraded  systems  to  support 
older  systems  that  had  not  yet  transitioned  through  upgrade. 

c.  Cost  of  Post-Deployment  Software  Support  (PDSS) 

Once  modularized,  post-deployment  software  support  was  less  expensive. 
That  is,  software  changes  made  to  modular  components  were  less 
complex  (therefore,  less  expensive)  than  changes  made  to  fully  integrated 
systems.  The  reason  was  that  the  changes  must  be  carefully  controlled  at 
key  interfaces,  but  there  was  less  work  required  to  deal  with  unexpected 
secondary  effects.  The  new  application  software  was  “plug  and  play,”  with 
minor  or  no  changes  to  the  middleware,  while  most  other  (unaffected) 
application  software  was  simply  reused.  The  portability  of  modular 
software  to  other  systems  and  other  platforms  offered  additional 
opportunity  for  PDSS  cost  savings  or  cost  avoidance.  In  the  A-RCI 
example,  application  software  used  in  submarines  for  towed-array  sonar 
might  also  be  used  in  spherical,  hull,  and  high-frequency  sonar  systems. 
That  same  application  software  might  further  be  used  in  (or  possibly 
originate  from)  surface  ship  sonar  or  aircraft  anti-submarine  warfare 
applications. 

d.  Other  Logistics  Support  Costs 

Additional  cost  avoidance  has  accrued  from  logistics  aspects  of  A-RCI,  as 
shown  below.^® 

o  Inventory,  valued  at  $600  million  was  converted  to  Just-in-Time 
contractor-provided  support.  This  initiative  avoided  $2  million  in 
Navy  Working  Capital  Funds. 

o  Interactive  multimedia  instruction  avoided  $19  million. 

o  Outfitting  spares  reduction  avoided  $3  million. 


William  M.  Johnson,  “The  A-RCI  Process — Leadership  and  Management  Principles,”  Naval 
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o  Interactive  Electronic  Technical  Manuals  (lETMs)  avoided  cost 
of  more  than  $1  million. 

4.  Logistics  Impact 

A-RCI  impacts  on  logistics  were  generally  very  positive. 

a.  Integration 

In  A-RCI/APB,  systems  development  and  logistics  were  integrated, 
obtaining  several  benefits.  Software  technicians  who  responded  to 
“trouble  calls,”  were  also  programmers — with  the  result  that  finding 
weaknesses  in  fielded  software  led  to  improvements  in  future  Advanced 
Processing  Builds.  Additionally,  many  of  the  software  products  were  re¬ 
used  in  Interactive  Electronic  Technical  Manuals  (lETMs),  training 
devices,  and  in  training  curriculums.  The  system  developer-logistician 
integration  not  only  saved  resources  but  also  sped  up  logistics  support — 
which  typically  lags  behind  system  introduction.  For  A-RCI  predecessors, 
“training  lags  of  three  years  were  not  uncommon.  Today,  [A-RCI/APB] 
training  lag  time  is  measured  in  days.”^® 

b.  Training 

Modularized  systems  generically  (and  in  the  case  of  A-RCI)  have  the 
potential  to  reduce  training  burdens.  Training  packages,  or  portions 
thereof,  could  potentially  be  re-used — not  only  across  systems  but  across 
platforms. 

Sometimes  offered  as  a  criticism  of  A-RCI,  operators  and  maintenance 
technicians  needed  frequent  updates  and,  possibly,  needed  to  be  familiar  with 
multiple  generations  of  sonar  systems.  However,  as  cumbersome  as  this  seems,  it 
may  have  been  no  more  difficult  than  in  the  past.  Multiple  generations  of  warfighting 
systems  in  service  at  the  same  time  have  been  a  fact  of  life  for  many  years  across 
the  DoD.  Nevertheless,  there  seems  little  question  that  the  rapid  op  tempo  of  A-RCI 
evolutions  did  present  training  challenges  for  operators  and  maintainors. 

c.  Maintenance  Free  Operating  Period  (MFOP) 

One  A-RCI  initiative  that  was  unforeseen  at  the  outset  was  the  creative 
employment  of  spare  components  in  a  way  that  reduced  the  need  for 
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“open  cabinet”  repairs  to  sonar  systems  while  on  deployment.  MFOP 
became  feasible  because  commercial  processors  take  less  space  than 
their  developmental  predecessors.  It  was  found  that  sonar  system  spare 
components  could  be  installed  and  fully  powered  in  electronics  cabinets, 
enabling  them  to  be  used  in  the  event  of  a  primary  system  malfunction. 
Then,  if  a  system  failure  occurred  in  the  operating  system,  that  function 
could  be  switched  to  a  “spare”  module  without  physical  access  to  the 
cabinet.  The  necessary  quantities  of  “plugged-in”  spares  were  calculated 
that  would  achieve  a  high  likelihood  of  continued  operation.  As  a  result, 
“open  cabinet”  maintenance  while  underway  has  been  virtually  eliminated. 
MFOP  has  been  a  success  in  terms  of  quality  of  life  because  open-cabinet 
repair  while  underway  was  difficult  to  accomplish.  There  also  have  been 
system  readiness  ramifications  because  operational  availability  has 
increased.  Finally,  there  have  been  maintenance-strategy  implications, 
because  now  open-cabinet  maintenance  can  be  accomplished  almost 
exclusively  by  contractor  personnel  after  completion  of  a  deployment. 

o  A-RCI  has  demonstrated  that  system  upgrades  can  include 
logistics  focus.  Maintenance  Free  Operating  Period  (MFOP), 
described  above,  is  an  example  of  logistics  focus. 

o  As  previously  pointed  out,  modularization  impacts  LOG  through 
less  expensive  replacement  of  obsolete  hardware  and  software. 

o  PDSS  is  simplified  because  software  is  re-used  where  possible. 
A-RCI  has  also  shown  that  much  of  the  necessary  maintenance 
can  be  shifted  to  contractor  logistics  support  (CLS); 
demonstration  has  shown  that  some  software  defects  can  be 
addressed  remotely  by  CLS,  using  secure  networks. 

o  The  A-RCI  experience  has  shown  that  the  character  of  sonar 
training  has  changed.  It  has  been  re-focused  to  address 
performance  weaknesses.  Some  maintenance  training  has 
been  reduced  or  eliminated  as  the  result  of  MFOP,  providing  the 
potential  for  increased  employment  training.  Upgraded  training 
packages  still  are  necessary,  of  course,  to  achieve  full  benefit  of 
the  system  modifications.^^ 
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G.  Other  Ramifications 


1.  Portability  and  Software  Re-use 

The  portability  of  modular  software  to  other  systems  and  other  platforms 
offers  additional  opportunity  for  cost  savings  or  cost  avoidance.  In  the  A-RCI 
example,  application  software  used  in  submarines  for  towed  arrays  has  been  re¬ 
used  in  spherical,  hull,  and  high-frequency  sonar  systems.  That  same  application 
software  also  has  been,  or  potentially  will  be,  used  in  surface  ship  applications  and 
even  in  aircraft  ASW  applications.  In  addition  to  the  potential  cost  savings  or 
avoidance  in  software  development  and  the  use  of  common  processors,  there  is 
also  an  expected  reduction  is  PDSS. 

2.  Scalability 

One  of  the  questions  resulting  from  A-RCI  is  whether  the  modular  open 
systems  approach  is  applicable  in  larger,  more  complicated  applications.  For 
example,  is  MOSA  applicable  to  other  submarine  systems,  surface  ship 
systems,  aircraft,  system  of  systems  like  the  Army’s  Future  Combat  Systems, 
or  even  National  Missile  Defense?  Portions  of  this  question  have  been 
answered  already,  as  described  below. 

3.  Implementation 

Two  warfighting  systems,  Virginia  Class  Submarine  and  E-2  Hawkeye 
Electronic  Surveillance  Aircraft  have  successfully  implemented  MOSA. 

•  Virginia  Class  Submarine  Non-propulsion  Electronic  Systems  (NPES) 
have  been  developed  successfully  using  MOSA.  This  undertaking 
included  23  different  sub-systems — including  tactical  control  and  weapons 
control — that  form  into  a  coherent  warfare  system  of  systems  (SoS). 

•  E-2  Hawkeye  Aircraft,  a  legacy  system,  has  been  modularized  and 
upgraded. 
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Two  of  our  most  challenging  warfighting  systems,  the  Army’s  Future  Combat 
Systems  (FCS)  and  National  Missile  Defense,  seem  to  be  good  candidates  for 
MOSA. 


•  The  FCS  is  a  family  of  systems  (FoS);  it  is  expected  to  comprise  18 
different  platforms — a  mix  of  manned  and  unmanned,  air  and  ground 
systems — plus  a  network  that  will  link  the  platforms.  There  will  be 
modularization,  system  of  systems  (SoS)  at  the  platform  level.  Insofar  as 
the  platforms  are  treated  as  a  “family,”  reuse  of  software  modules  may 
offer  significant  savings;  if  MOSA  is  feasible,  significant  savings  or  cost 
avoidance  potentially  would  extend  from  development  through 
sustainment.  MOSA  seems  to  offer  a  useful  technical  and  business 
strategy. 

•  Similarly,  National  Missile  Defense  must  be  modularized  to  permit 
development  of  the  many  different  sensors,  weapons  platforms,  command 
and  control  functions,  and  communications  links.  If  feasible,  MOSA 
seems  an  appropriate  strategy  for  development,  upgrade,  and 
sustainment.  There  may  be  constraints  to  MOSA;  for  example,  within  the 
command  and  control  system,  real-time  intercept  calculations  might  limit 
the  extent  of  modular  design.  However,  TOC  savings  and  a  reduced 
logistics  burden  are  worth  pursuing.  The  DoD  5000.1  requires  developers 
to  employ  MOSA,  if  feasible,  but  recognizes  potential  scalability  limitations 
in  the  use  of  MOSA.^® 

4.  Treatment  of  Obsolescence 

From  a  logistics  perspective,  one  of  the  major  benefits  of  open  systems  is  the 
freedom  to  exercise  the  “plug  and  play”  feature  at  such  time  as  a  module  becomes 
obsolete  and  no  longer  able  to  be  supported.  This  is  useful  because  all  of  our 
warfighting  systems  experience  sustainment  issues  as  soon  as  production  has  been 
completed.  In  some  cases,  this  occurs  due  to  competitive  pressure — e.g.,  off-shore 
competition.  In  other  cases,  legal  or  environmental  issues  may  motivate  suppliers  to 
stop  producing — e.g.,  castings  and  forgings  in  the  early  1970s,  due  to  new 
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environmental  law.  In  yet  other  cases,  vendors  might  leave  a  business  due  to  other 
market  pressures — e.g.,  a  company’s  capability  to  accomplish  programming  support 
for  a  warfighting  system  in  a  particular  software  language  might  change  as  the  result 
of  unrelated  market  pressures.  MOSA  contributes  flexibility  to  react  to  any  of  these 
examples.  A-RCI/APB  is  now  seen  as  an  example  of  the  flexibility  to  act  proactively. 
In  the  future,  that  same  flexibility  may  be  useful  in  response  to  component 
obsolescence. 

5.  Comparison  of  Legacy  versus  New  Systems 

Legacy  warfighting  systems  that  have  converted  to  MOSA  are  in  better 
competitive  position  for  upgrade  funding  than  those  unable  to  become  modularized. 
Stakeholders  will  gravitate  to  modularized  systems  and  open  systems  architecture 
because  of  the  likelihood  of  seeing  results  faster,  with  “more  bang  for  the  buck.” 

New  warfighting  systems  may  contribute  to  their  own  “undoing”  by  failing  to  fully 
embrace  MOSA,  thereby  becoming  uncompetitive  for  future  funding  in  the  process. 
Based  on  the  A-RCI  experience  (along  with  Virginia  Class  Submarine  technical 
refreshment  strategies),  future  ship  acquisitions  would  appear  to  demand  that 
aggressive  technical  refreshment  strategies  be  used  in  new  ship  construction;  the 
intended  result  would  be  installation  of  the  latest  mature  technologies  onto  the 
Navy’s  newest  warships,  while  minimizing  the  incidence  of  obsolete  technologies  at 
the  time  of  a  ship’s  entry  into  the  fleet. 

6.  Financial  Management 

A-RCI  funding  streams  have  changed  from  the  widely  recognized  pattern  of 
RDT&E,  followed  by  Production,  followed  by  O&M.  As  spiral  development 
continues,  there  is  need  for  continued  RDT&E  funding,  albeit  at  a  reduced  level, 
taking  advantage  of  MOSA.  Processor  and  APB  upgrades  require  a  continuing 
stream  of  Procurement  funding,  but  at  a  reduced  level  by  taking  advantage  of 
COTS.  Finally,  O&M  funding  supports  sustainment,  just  as  in  the  traditional  case 
but  at  a  reduced  level,  taking  advantage  of  CLS  efficiencies  and  reduced  life-of-type 
buys  and  obsolescence  cost. 
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7.  JCIDS 

Spiral  Acquisition  must  be  rooted  in  the  JCIDS  process  to  ensure  proposed 
acquisitions  address  required  capabilities,  avoid  unnecessary  redundancy,  and 
provide  interoperability  with  other  warfighting  systems.  The  JCIDS  process  requires 
reviews  and  approvals  that  are  important,  but  also  are  time-consuming  and  may 
contribute  to  program  delays.  There  appears  to  be  a  risk  that  rapid  op  tempo  spiral 
developments  potentially  may  collide  with  slower-moving  JCIDS  processes,  resulting 
in  incomplete  reviews,  inadequate  user  direction,  or  program  delay. 

8.  Testing 

A-RCI  testing  included  Developmental  Testing  in  support  of  market  survey,  in 
development  (Build/Test/Build),  and  at  sea  to  ensure  that  upgraded  modules 
performed  correctly  in  the  system  of  systems  or  family  of  systems.  New  COTS 
hardware  and  Advanced  Processing  Builds  (APB)  get  a  thorough  technical  shakeout 
to  ensure  they  work  correctly.  However,  the  A-RCI  experience  demonstrated  a 
structural  impediment  to  completion  of  operational  testing.  Operational  Testing 
typically  examines  suitability  and  effectiveness  of  the  warfighting  system  and  is 
accomplished  “end  to  end.”  Unfortunately,  end-to-end  testing  is  expensive  and  time- 
consuming  for  an  operational  asset.  End-to-end  operational  testing  has  not 
synchronized  well  with  the  A-RCI/APB  process  as  testing  is  time  consuming, 
expensive  and  may  not  always  be  necessary  with  spiral  upgrades.  End-to-end 
operational  testing  has  its  place,  but  possibly  not  in  every  spiral  of  an  evolutionary 
development. 

In  June  2005,  COMOPTEVFOR  published  guidance  and  a  framework  for 
integrated  testing — that  is,  combining  operational  testing  (OT),  developmental 
testing  (DT),  and  contractor  testing  (CT).  The  intent  of  this  directive  was  to  identify 
and  resolve  Critical  Operational  Issues  (COIs)  as  early  as  possible  and  to  use 
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operational  testing  to  confirm  mission  performance  instead  of  conducting  an  “all 
encompassing  system  evaluation.”^® 

H.  Summary 

Acoustic  Rapid  COTS  Insertion/Advanced  Processing  Build  (A-RCI/APB) 
shows  the  promise  of  a  modular  open  systems  approach  (MOSA).  A-RCI  was  a 
leader,  finding  its  way  when  few  rules  and  guidelines  were  available.  Today,  there  is 
a  body  of  information  showing  the  benefits  of  A-RCI.  Rules  and  guidelines  have 
emerged  to  help  guide  other  programs  through  MOSA;  many  of  those  guidelines  are 
the  result  of  the  A-RCI  experience.  Other  programs’  successes,  such  as  Virginia 
Class  Non-Propulsion  Electronic  systems  (NPES)  and  E-2  Hawkeye  aircraft 
upgrade,  suggest  that  A-RCI  was  not  simply  a  one-time  success.  In  the  aggregate, 
these  several  successful  programs  are  an  indication  that  other  acquisition  programs 
might  use  MOSA  with  similar  benefits.  The  A-RCI  experience  indicates  that  some 
Acquisition  processes  need  to  be  retooled  to  interface  with  and  reap  the  advantages 
of  rapid  spiral  development. 


^®  Commander,  Operational  Test  and  Evaluation  Force,  U.S.  Navy,  “Operational  Test  and  Evaluation 
(OT&E)  Framework  and  the  Integrated  Testing  (IT)  Methodology”  (Norfolk,VA:  author,  28  June  2005), 
End  1.  Policy  and  Information  Notice  05-1. 
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VI.  Conclusions  and  Recommendations 


1.  A-RCI/APB  has  successfully  applied  MOSA,  deriving  major 
performance  and  logistics  improvements. 

The  A-RCI  program  drastically  changed  its  technical  and  business 
practices — embracing  business  and  technical  principles  and  disciplined 
processes  that  currently  comprise  the  Modular  Open  Systems 
Approach.  The  results  were  a  series  of  substantial  technical 
improvements,  reduced  cycle-times,  transition  to  COTS  processors, 
and  software  sharing  across  weapon  platforms. 

2.  A-RCI  demonstrated  significant  Total  Ownership  Cost  or  system 
Lifecycle  Cost  benefits. 

The  Navy  is  currently  validating  a  historical  cost  comparison  of  A-RCI 
and  its  predecessor  system.  Preliminary  results  compiled  from  10 
years  of  data  on  both  A-RCI  and  its  predecessor  indicate  that  lifecycle 
cost  has  improved  by  nearly  5:1 . 

3.  The  A-RCI/APB  example  shows  that  MOSA  can  be  applied  to  a 
legacy  system. 

A-RCI/APB  was  modularized  by  first  separating  software  from 
hardware.  The  integrated  software  was  further  modularized  into 
functionally  partitioned  software  modules  and  transportable 
middleware.  MCSA  includes  feasibility  assessment  of  open  system 
solutions — an  essential  business  and  technical  consideration  when 
starting  with  a  fully  integrated  legacy  solution. 

4.  A-RCI/APB  demonstrates  that  modular  upgrades  can  be 
accomplished  very  rapidly  through  spiral  development,  in 
contrast  to  traditional  systems  development. 

A-RCI/APB  was  able  to  produce  an  Advanced  Processing  Build 
annually  and  upgrade  CCTS  processing  hardware  every  two  years. 
Implementations  in  the  submarine  fleet  resulted  in  each  submarine 
getting  upgraded  software  at  about  two-year  intervals  and  new  CCTS 
processors  at  approximately  four-year  intervals. 

5.  A-RCI/APB  experience  suggests  there  are  operational  test  issues 
that  must  be  worked  out. 

Cperational  testers  have  a  bias  for  end-to-end  testing,  which  is 
expensive  and  slow,  but  thorough.  Such  an  approach  to  testing  does 
not  fit  well  with  rapid  spiral  development.  A-RCI/APB  included  at-sea 
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testing  on  operational  submarines,  but  this  was  not  end-to-end  testing 
in  the  traditional  mold.  OPTEVFOR’s  2005  policy  directive  suggests 
that  the  Navy  is  trying  to  streamline  OT  to  better  fit  rapid  op  tempo 
spiral  development  programs. 

6.  The  op  tempo  of  A-RCI/APB  and  the  pace  of  JCIDS  suggest 
possible  synchronization  issues  that  shouid  be  evaiuated  to 
ensure  that  appropriate  joint  reviews  proceed  without  deiaying 
the  spirai  development  process. 

A-RCI/APB  spirals  are  receiving  an  annual  JCIDS  review.  Publication 
of  a  JCIDS  supplement  pertaining  to  rapid  op  tempo  spiral 
developmental  programs  would  be  highly  beneficial. 

7.  Funding  implications  of  A-RCI  need  to  be  studied  and 
understood. 

Traditional  funding  profiles  do  not  support  the  A-RCI  example. 
Traditional  funding  entails  three  overlapping  funding  profiles  of 
increasing  size:  RDT&E,  Procurement,  and  the  O&S  accounts 
(primarily  O&M  and  military  personnel).  Annual  increments  of  spiral 
development  require  continuous  streams  of  RDT&E,  Procurement,  and 
the  O&S  accounts — smaller,  more  flat  annual  amounts,  continuously, 
as  long  as  the  annual  spirals  continue. 
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Appendix  A.  Potential  Template  Opportunities  for 
Support  of  Modular  Open  Systems  Approach 
(Based  on  A-RCI/APB  Experience) 

1.  Technology  Open  Systems  Strategy 

2.  Business  Modular  Open  Systems  Approach 

3.  Culture  Changes  Necessary  to  Support  Modular  Open  Systems  Approach 

4.  Leadership  Support  Required  at  Critical  Levels 

5.  Users’  Participation 

6.  Testing  Interfaces  that  are  Streamlined  to  Support  Rapid  Acquisition  OPTEMPO 

7.  JCIDS  Interfaces 

8.  Logistics — Sustainment  Structures  and  Payoffs 

9.  Training  Impacts 

10.  Upgrade  Process/Implementation  Strategy  and  Processes 

11.  Detailed  Schedule  Planning,  Including  Milestone  Reviews 
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Appendix  B.  A-RCI/APB  Supporting  Organizations 


(Extracted  from  Sonar  Development  Working  Group  (SDWG),  1998-99  Year  in 
Review) 


CHAPTER  2.  ORGANIZATION 
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Figure  2-1.  SDWG  Organization 


In  order  to  manage  the  APB  Process  and  the  transition  of  new  algorithms  for  fleet  use,  an 
Integrated  Product  Team  (IPT)  structure  has  been  adopted  and  is  provided  in  Figure  2-1. 
However,  it  should  be  noted  that  the  management,  direction  and  decision-making 
responsibility  for  the  process  and  content  of  the  individual  systems  continue  to  reside  with 
the  cognizant  Program  Offices:  PMS425  for  in-service  submarine  sonar,  PMS401  for  the  VA 
Class  submarine  sonar  system,  PMS411  for  the  SQQ-89(V)  program,  PMS500  for  DD-21 
and  PD-18  for  the  lUSS  program.  In  concert  with  the  Program  Offices,  ASTO  has  significant 
respcnsibility  in  delivering  the  APB  technologies  for  insertion  into  the  baseline  sonar 
systems. 

Various  working  groups,  chartered  by  the  program  offices,  are  chaired  according  to 
personnel  expertise  and  provide  a  broad  representational  cross-section  of  the  best  and 
brightest  from  the  fleet.  Navy  Laboratories,  University  Laboratories  and  industry. 
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2.1  SDWG 


The  SDWG,  jointly  chaired  by  Victor  Gavin  (PMS425),  Kevin  Collins  of  the  Naval  Undersea 
Warfare  Center  Division  Newport  (NUWCDIVNPT)  and  Joe  Grant  (PMW-182),  provides  a 
monthly  forum  for  discussion  of  topics,  updates  and  issues  related  to  the  APB  process.  It 
provides  a  clearinghouse  for  communication  across  the  working  groups  and  a  forum  to  brief 
recommendations  and  works  in  progress  from  the  various  working  groups.  Meetings  are 
held  monthly  and  agenda  items  are  developed  based  on  priorities  established  by  the  fleet 
and  the  sponsor  (Chief  of  Naval  Operations  (CNO)  N87)  with  inputs  from  the  Program 
Offices  and  working  group  constituents. 

2.2  Advisory/Review  Groups 

2.2.1  Technical  Advisory  Group  (TAG) 

The  TAG,  an  extension  of  the  original  SSTP  including  additional  advisors  of  national  repute 
and  organizational  leads  from  key  laboratories,  advises  the  Program  Offices,  the  SDWG  and 
the  sponsor  on  all  matters  related  to  the  APB  process.  Chaired  by  Jim  Griffin  (N875T),  the 
TAG  provides  an  additional  check  and  balance  to  ensure  integrity  across  the  entire  APB 
process  described  in  Chapter  1.  The  TAG  reviews  issues  such  as  progress  toward  the  dB 
budget,  plans  for  Step  3  and  Step  4  APB  testing,  results  of  Step  2  algorithm  testing  and 
various  other  technical  issues. 

2.2.2  Near  Term  Working  Group  (NTWG) 

A  sister  organization  to  the  SDWG,  the  NTWG  is  chartered  to  coordinate  the  procurement, 
testing  and  assistance  to  the  submarine  Type  Commanders  (TYCOMs)  for  the  shipboard 
installation  of  advanced  augmentation  bridge  systems  for  fleet  deployments.  Chaired  by 
LCDR  Rutledge  Webb,  Office  of  the  Chief  of  Naval  Operations  (OPNAV),  the  NTWG 
provides  recommendations  and  assessments  to  N87  with  respect  to  the  following: 

■  Procurement  and  Support  of  acoustic  and  combat  control  augmentation  systems 
required  to  improve  submarine  acoustic  superiority  and  tactical  control 

■  Augmentation  system  installation  configuration  and  support  for  fleet  needs 

■  APB  functions,  test  and  evaluation  process 

■  Planned  improvements/upgrades  to  fleet  acoustic  and  combat  control  systems 

The  NTWG  is  responsible  for  migrating  the  APB-99  technology  into  the  Automated  Fleet 
Towed  Array  System  (AFTAS)  hardware  suite  under  the  AEP  program  described  more  fully 
in  Chapters.  The  AEP  is  scheduled  for  fleet  introduction  in  late  1999. 

2.2.3  Sensor  Optimization  IPT  (SOlPT) 

The  SOlPT  is  a  senior  level  organization  providing  high-level  management  peer  review  to 
advanced  development  programs.  Chaired  by  James  Thompson  (ASTO),  the  SOlPT  assists 
in  R&D  program  planning  and  provides  recommendations  for  funding  of  future  advanced 
development  initiatives. 

2.2.4  Tactical  Integration  Advisory  Group  (TIAG) 
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The  TIAG  is  a  forum  of  senior  representatives  established  to  monitor  the  future  of  tactical 
control  initiatives.  Chaired  by  CAPT  Claude  Barron  (PMS401),  the  TIAG  provides  support 
and  recommendations  to  the  SDWG  in  defining  requirements  for  APBs  and  their  utility  in 
improving  tactical  control. 

2.3  Functional  Support  Groups 

The  Functional  Support  Groups  carry  out  the  essential  tasks  to  support  the  transition  of  the 
APBs  to  the  target  program  including  end-to-end  string  testing  in  the  laboratory  and  at-sea, 
predictions  of  the  performance  improvements  of  the  processing  and  the  development  of 
laboratory  and  database  infrastructure. 

2.3.1  Data  Support  Group  (DataSG) 

The  DataSG  is  responsible  for  coordinating  data  collection  requests  and  identifying  and 
providing  data  segments  from  relevant  blue-on-blue  and  blue-on-orange  encounters  for 
controlled  distribution.  The  DataSG  provides  open  sets  (signatures  known  prior  to  user 
review)  to  the  R&D  community  and  open  and  closed  data  sets  (signatures  revealed  only 
during  testing)  to  various  SDWG  groups  including  the  Signal  Processing  Working  Group 
(SPWG),  the  Automation  Working  Group  (AWG)  and  the  TEASG.  The  DataSG  is  chaired  by 
Bob  Amundson  (ONI). 

2.3.2  Development  Support  Group  (DevSG) 

The  DevSG  is  responsible  for  defining  and  implementing  the  equipment  suites  required  for 
the  research,  development  and  testing  of  the  APBs.  The  DevSG  is  also  chartered  to  support 
the  rapid  dissemination  of  approaches  to  industry  and  development  of  the  Middleware 
Support/Certification  Plan.  Chaired  by  Rich  Matis  of  NUWCDIVNPT,  the  DevSG  includes 
representatives  from  ONI,  NUWCDIVNPT,  JHU/APL,  Digital  Systems  Resources  (DSR), 
Massachusetts  Institute  of  Technology/Lincoln  Laboratory  (MIT/LL),  and  Naval  Surface 
Warfare  Center  Crane  Division  (NSWCCD). 

2.3.3  Test,  Evaluation,  Assessment  and  Support  Group  (TEASG) 

The  TEASG  is  responsible  for  providing  independent  test  and  evaluation  for  both  in-lab 
(Step  3)  and  at-sea  (Step  4)  testing  of  the  APBs.  Chaired  by  Tom  Stewart  (JHU/APL),  the 
TEASG  is  also  responsible  for  managing  evaluation-to-evaluation  compatibility  and 
providing  a  performance  comparison  with  the  baseline  system.  The  TEASG  is  comprised  of 
representatives  from  NUWCDIVNPT,  JHU/APL,  Applied  Research  Laboratory,  University  of 
Texas  (ARL:UT),  MITRE,  DSR,  ONI  and  Commander,  Submarine  Development  Squadron 
12  (CSDS-12). 

At-sea  testing  is  the  principal  focus  of  the  APB  test  process,  permitting  live  examination  of 
the  strengths  and  weaknesses  of  the  new  build  and  quantitative  measurements  of 
performance.  Weaknesses  can  be  addressed  and  mitigated  during  transition  to  IDP.  In 
addition,  at-sea  testing  provides  the  essential  confidence  required  by  the  TYCOMs  to 
endorse  the  use  of  the  new  processing  for  patrols  and  deployments.  Well-constructed  at-sea 
tests  also  provide  important  data  collection  opportunities  for  further  R&D  tasking.  Laboratory 
testing  provides  the  essential  looks  at  diverse  threat  signatures  and  geometries  that  are 
unavailable  in  at  sea  blue-on-blue  testing,  adding  an  additional  level  of  understanding  and 
confidence  in  the  algorithms.  It  also  provides  assurance  to  the  community  contributors  that 
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their  algorithms  have  been  implemented  and  perform  properly.  Finally,  laboratory  testing 
provides  an  early  opportunity  for  crew  familiarization  and  training  with  the  new  processing. 

In  addition  to  testing  of  APBs,  the  TEASG  oversees  the  continued  measurement  and 
assessment  of  fielded  ARCI  systems  through  the  ARCI  Engineering  Measurement  Program. 
The  TEASG  can  then  assess  performance  of  the  fielded  system,  compare  the  performance 
with  that  expected  based  on  APB  testing  and  feed  back  assessment  results  into 
development. 

2.3.4  Modeling  and  Prediction  Support  Group  (MPSG) 

The  MPSG  provides  analytical  bounds  on  performance  of  the  algorithms  incorporated  in  an 
APB.  It  also  provides  for  the  development  of  models  to  adequately  project,  with  meaningful 
metrics,  the  performance  of  the  sonar  system  in  areas  of  interest.  The  MPSG  is  chaired  by 
Garry  Jacyna  (MITRE)  and  includes  representatives  from  NUWCDIVNPT  and  JHU/APL. 

2.3.5  Concept  of  Operations  (CONOPS)  and  Operator-Machine  Interface  (OMI)  Support 
Group  (COSG) 

The  COSG  defines  the  OMI  (notional  control  and  display  schemes)  and  operational 
utilization  of  the  processing  algorithms  developed  by  the  SPWG  and  the  AWG.  The  primary 
fleet  voice  for  determining  the  priority  of  APB  improvements  in  the  areas  of  acoustic  signal 
detection,  system  automation  and  tactical  information  management,  the  COSG  also 
develops  and  conducts  crew  familiarization  training  for  platforms  receiving  the  APB  system 
upgrades. 

The  COSG  is  chaired  by  STSCM  Terry  Stuckart  (CSDS-12)  and  is  comprised  principally  of 
active  duty  senior  enlisted  personnel,  civilian  representatives  from  the  program  offices, 
system  development  contractors  (Lockheed  Martin  Undersea  Systems  (LMUSS)  and  DSR), 
and  ACINT  experts  from  the  fleet. 

2.3.6  Training  IPT 

The  Training  IPT  is  responsible  for  the  development  of  a  process  for  a  common  training 
approach  among  the  submarine  operational,  technical,  training,  and  intelligence 
communities.  Once  this  process  is  developed  and  approved,  the  Training  IPT  will  oversee  its 
implementation  and  provide  periodic  assessments  to  the  program  office  with  prioritized 
recommendations  for  APB  changes  and  training  improvements. 

Areas  of  focus  for  the  process  are  the  development  of  metrics,  training  of  operators  on 
system  installations  and  upgrades,  improving  maintenance  training  and  identification  of 
potential  system  upgrades  to  enhance  operator  performance. 

The  Training  IPT  is  chaired  by  a  PMS4252  representative  and  is  comprised  of 
representatives  from  CNO  N872,  CNO  N879,  the  TYCOMs,  NAVSEA  92L1,  Chief  of  Naval 
Education  and  Training  (CNET),  ONI,  JHU/APL,  SOBT  and  LMUSS. 

2.4  Execution  IPTs 

Execution  IPTs  are  chartered  to  provide  program  direction  and  asset  management  for  the 
Peer  Review  Working  Groups.  Although  the  Execution  IPTs  may  merge  over  the  next  two 
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years  as  the  APB  process  stabilizes  and  cross-sensor  fusion  is  addressed,  the  following 
provides  a  summary  listing  of  the  current  Execution  IPTs  and  their  responsibilities. 

2.4.1  Towed  Array  Execution  IPT 

Chaired  by  Bob  Zarnich  (ASTO),  this  IPT  has  responsibility  for  the  delivery  of  towed  array 
and  hull  array  APB  processing.  The  IPT  composition  is  determined  by  ASTO  and  PMS425 
and  currently  includes  representatives  from  PMS425,  NUWCDIVNPT,  the  chairs  of  the  Peer 
Review  Working  Groups  and  DSR,  the  towed  array/hull  array  APB  integration  agent  for 
APB-98  and  APB-99. 

2.4.2  Sphere  Array  Execution  IPT 

Co-chaired  by  George  Zvara  (NUWCDIVNPT)  and  Howard  Taylor  (LMUSS),  this  IPT  has 
responsibility  to  manage  the  advanced  development  of  improved  sonar  Spherical  Array  (SA) 
detection,  classification  and  localization  functionality.  ASTO  and  PMS425  determine  the  IPT 
representatives.  A  merger  of  the  Sphere  Array  Execution  IPT  with  both  the  Towed  Array 
Execution  IPT  and  the  High  Frequency  Execution  IPT  is  planned  in  the  near  future  to 
support  a  common  Low  Frequency  (LF),  Medium  Frequency  (MF)  and  High  Frequency  (HF) 
Execution  IPT. 

2.4.3  Towed  Array-Wet  End  Execution  IPT 

Representatives  from  the  Towed  Array-Wet  End  Execution  IPT  have  been  monitoring  the 
Navy’s  efforts  over  the  course  of  the  past  year  to  develop  a  common  thin  line  array  and/or 
common  components  for  a  thin  line  array  to  support  the  submarine,  surface  and  lUSS 
communities.  Chaired  by  Jean-Pierre  Feuillet  (PMS411),  the  Towed  Array-Wet  End 
Execution  IPT  will  become  more  actively  engaged  in  this  effort  in  the  near  future  once  the 
initiative  leaves  the  planning  stages  and  is  under  contract. 

2.4.4  High  Frequency  Execution  IPT 

The  High  Frequency  Execution  IPT  maintains  responsibility  for  the  delivery  of  high 
frequency  sail  and  chin  processing  for  the  HF  APB-99  build  and  development  of  HF  APB-01. 
The  IPT,  chaired  by  Jim  Broughton  (ASTO),  consists  of  representatives  from  ASTO, 
PMS425,  NUWCDIVNPT,  ARL:UT  and  LMUSS.  As  stated  previously,  plans  call  for  a  future 
merger  of  the  HF  Execution  IPT  with  the  Towed  Array  and  Sphere  Array  Execution  IPTs. 

2.4.5  Active  Classification  Execution  IPT 

Active  Classification  is  fundamentally  different  than  passive  classification.  Chaired  by  Jeff 
Jones  (ASTO),  the  Active  Classification  IPT  is  examining  technologies  to  improve  the  active 
classification  process.  Committee  membership  presently  is  comprised  of  NUWCDIVNPT, 
ASTO,  and  CSDS-12.  The  focus  during  1998  and  1999  has  been  to  examine  the  viability  of 
transition  of  automation  technology  from  the  surface  ship  combatant  community.  These 
efforts  are  more  fully  detailed  in  Chapter  3. 

2.4.6  SQQ-89  Execution  IPT 

The  SQQ-89  Execution  IPT,  chaired  by  Jean-Pierre  Feuillet  (PMS411),  was  established  in 
late  1998  under  the  joint  PMS425/PMS41 1/PMS415  MOU  described  in  Chapter  1.  The 
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focus  of  this  IPT  is  on  extending  the  appiication  of  a  common  acoustic  processing  system  to 
surface  ships.  The  iPT  provides  technicai  direction  to  the  respective  program  offices  for 
deveiopment  of  the  Common  Acoustic  Processor  for  Surface  Combatants  (SURCAP).  The 
iPT  wiii  be  co-chaired  by  a  PMS425  designated  representative. 

2.4.7  lUSS  Execution  IPT 

Chartered  in  1998,  the  iUSS  Execution  iPT  is  responsibie  for  providing  aii  technicai  direction 
for  deveiopment  of  the  NCAP  and  for  managing  the  integration  of  the  APB-deveioped  NCAP 
components  with  other  iUSS  processing  components.  The  iUSS  Execution  iPT  is  chaired  by 
S.  Lachtman  (SPAWAR). 

2.5  Peer  Review  Groups 

The  Peer  Review  Groups  address  the  functionai  and  technicai  issues  required  ieading  to  the 
recommendations  for  improvements  to  the  sensor  processing.  The  groups  provide 
recommendations  to  the  Execution  iPTs  on  R&D  priorities,  inciuding  tasking  for  each  funded 
organization  and  provide  independent  test  and  evaiuation  of  candidate  aigorithms.  These 
working  groups  coiiectiveiy  survey,  deveiop  and  test  the  aigorithms  and  dispiays  (Step  1  and 
Step  2  of  the  APB  process)  and  monitor  progress  through  Step  4.  The  Program  Office  ieads 
of  the  Execution  iPTs  determine  the  chairs  and  membership  of  the  Peer  Groups,  focusing 
on  the  taients,  experience  and  capabiiities  of  the  individuais  rather  than  organizationai  ties. 

2.5.1  Automation  Working  Group  (AWG) 

The  focus  of  the  AWG  is  on  aigorithms  intended  to  automate  the  use  of  data  generated  by 
the  signai  processor  and  avaiiabie  for  dispiay.  This  typicaiiy  inciudes  processing  which 
repiaces,  assists  or  extends  the  traditionaiiy  operator-intensive  functions  (i.e.,  source 
detection  and  recognition,  tracking,  source  correiation,  ciassification  and  extraction  of 
tacticai  information)  and  aiso  may  inciude  source  intercept  and  identification,  echo  steai, 
source  iocaiization  and  decision  aids  for  vuinerabiiity  assessment  and  pianning. 

Working  with  fleet  representatives  from  CSDS-12  and  the  COSG,  the  AWG  identifies  and 
prioritizes  automation  needs  that  are  most  effective  for  fleet  use.  Foiiowing  the  four-step 
APB  process,  the  AWG  identifies  candidate  soiutions  for  those  needs  by  ieveraging  the  best 
aigorithms  avaiiabie  throughout  the  R&D  community.  AWG  members  evaiuate  those 
aigorithms  for  potentiai  use,  and  recommend  seiected  automation  products  for  integration 
into  the  APB  baseiine.  The  AWG  aiso  deveiops  effective  concepts  for  interface,  dispiay  and 
controi  of  automation  information,  and  encourages  deveiopers  to  work  those  key 
improvement  areas.  The  AWG  works  with  the  SPWG  and  system  deveiopers  to  ensure  that 
its  recommendations  properiy  account  for  processing  performance  and  system  sizing 
constraints. 

John  Stapieton  (JHU/APL)  chairs  the  AWG  which  is  comprised  of  representatives  from 
MiTRE,  DSR,  CSDS-12,  LMUSS,  MiT/LL  and  NUWCDiVNPT.  Non-members  can  participate 
in  open  sessions  of  the  AWG  known  as  the  Friends  of  AWG  (FoAWG). 

2.5.2  Signal  Processing  Working  Group  (SPWG) 

The  SPWG  is  responsibie  for  the  sonar  signai  processing  which  inciudes  array  processing, 
adaptive  beamforming  and  range  focusing  as  weii  as  narrowband  and  broadband  detection 
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improvements.  The  SPWG  is  jointly  chaired  by  Clark  Penrod  (ARL:UT)  and  Cliff  Carter 
(NUWCDIVNPT).  The  SPWG  includes  representatives  from  LMUSS,  ONI,  Orincon,  DSR, 
JHU/APL  and  CSDS-12.  Similar  to  the  AWG,  non-members  can  participate  in  open  sessions 
of  the  SPWG  known  as  the  Friends  of  the  SPWG  (FoSPWG). 

2.5.3  Parameter  Estimation  Working  Group  (PEWG) 

The  PEWG  addresses  issues  associated  with  extracting  target  and  noise  parameters  from 
the  array  data.  These  include  parameters  for  bearings  and  ranges  as  well  as  their  rates, 
frequencies  and  Dopplers.  The  initial  focus  of  the  PEWG  has  been  on  the  trackers  and 
identifying  the  causes  of  their  failures  and  the  need  to  reinstate  them.  Both  broadband  and 
narrowband  trackers  have  been  examined.  Art  Baggeroer  (MIT)  chairs  the  PEWG  which 
includes  representatives  from  AET,  George  Mason  University,  MIT/LL,  NUWCDIVNPT, 
SAIC  and  DARPA. 

2.5.4  High  Frequency  Peer  Group  (HFPG) 

The  HFPG  is  responsible  for  initiating  the  APB  process  for  the  HF  program  (including 
establishing  the  criteria  for  and  determining  APB  content)  and  for  reviewing  all  hull-mounted 
active  sonar  improvements  and  recommendations.  The  HFPG  is  chaired  by  Larry  Green 
(JHU/APL)  and  includes  representatives  from  ARL:UT,  NUWCDIVNPT,  LMUSS,  PMS425, 
JHU/APL,  MITRE,  Arctic  Submarine  Lab,  EG&G,  A&T,  ASTO  and  ARL:PSU.  The  HFPG 
focuses  on  the  following  HF  improvement  areas: 

■  Mine  avoidance 

■  Bottom  mapping 

■  Passive  and  Active  Anti-Submarine  Warfare  (ASW) 

■  Low  Probability  of  Intercept  Waveforms 

The  peer  group  has  covered  all  aspects  of  the  HF  APB  including  signal  processing, 
automation  (termed  Computer-Aided  Detection  (CAD)),  OMI,  and  test  and  evaluation. 

In  addition,  the  HFPG  community  will  begin  participating  as  subgroups  within  the  COSG, 
SPWG  and  AWG  as  part  of  the  planned  merger  of  the  Towed  Array,  Sphere  Array  and  HF 
Execution  IPTs. 

2.5.5  Operator  Feedback  IPT  (OFIPT) 

The  OFIPT  combines  the  efforts  of  the  operational,  technical,  training  and  intelligence 
communities  to  establish  feedback  in  the  form  of  training  and  operational  performance 
measurements.  This  includes  a  process  to  provide  feedback  to  program  offices  and  the 
training  community  on  the  submariner’s  performance  in  the  operation  of  the  sonar  system. 
The  feedback  will  be  used  to  enhance  the  effectiveness  of  improvements  in  sonar  upgrades 
by  determining  where  measurable  improvements  can  be  made  through  changes  to  the 
sonar  training  or  system  development  processes. 

A  primary  goal  of  the  OFIPT  is  to  gain  near-term  improvements  that  will  have  an  immediate 
payoff  for  improved  sensor  performance.  To  support  this  goal  and  develop  an  objective 
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operator  performance  feedback  process,  Measures  of  Performance  (MOPs)  and  Measures 
of  Effectiveness  (MOEs)  must  be  established  first  in  order  to  focus  on  those  skills  most 
effective  for  operators. 

This  IPT,  chaired  by  Tim  Oliver  (Booz-Allen),  includes  representatives  from  LMUSS,  ONI, 
JHU/APL,  NAVSEA  92L1  and  the  submarine  TYCOMs.  The  OFIPT  complements  the  AEMP 
system  evaluations  with  assessments  of  operator  performance. 
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2003  -  2006  Sponsored  Acquisition  Research 
Products 

Acquisition  Case  Series 

NPS-PM-06-041  Boudreau,  Michael.  Acoustic  Rapid  COTS  Insertion;  A  Case  Study 
in  Spiral  Development.  October  2006 

NPS-AM-06-008  Apte,  Aruna  U.,and  Eugene  (Joe)  Dutkowski.  Total  Ownership  Cost 
Reduction  Case  Study:  AEGIS  Microwave  Power  Tubes.  May  2006. 

UMD-CM-05-019  Lucyshyn,  William,  Rene  Rendon,  and  Stephanie  Novello. 
Improving  Readiness  with  a  Public-Private  Partnership;  NAVAIR's  Auxiliary  Power 
Unit  Total  Logistics  Support  Program.  July  2005. 

UMD-CM-05-018  Lucyshyn,  William,  and  Stephanie  Novello.  The  Naval  Ordnance 
Station  Louisville:  A  Case  Study  of  Privatization-in-Place.  August  2005. 

NPS-CM-04-008  Lucyshyn,  William,  Jeffrey  Cuskey,  and  Jonathan  Roberts. 
Privatization  of  the  Naval  Air  Warfare  Center,  Aircraft  Division,  Indianapolis.  July 
2004. 

NPS-PM-04-010  Lucyshyn,  William,  Keith  F.  Snider,  and  Robert  Maly.  The  Army 
Seeks  a  World  Class  Logistics  Modernization  Program.  June  2004. 

NPS-CM-03-005  Lamm,  David  V.  Contract  Closeout  (A).  September  2003. 

Sponsored  Report  Series 

UMD-LM-06-040  Gansler,  Jacques  S.,  and  William  Lucyshyn.  Evaluation  of 
Performance  Based  Logistics.  August  2006. 

UMD-CM-06-039  Dunn,  Richard  L..  Contractors  Supporting  Military  Operations. 
September  2006. 

NPS-FM-06-036  San  Miguel,  Joseph  G.  and  Donald  E.  Summers.  Public-Private 
Partnerships  for  Government  Financing,  Controlling  Risk,  and  Value  for  Money:  The 
UK  Experience.  September  2006. 

NPS-AM-06-035  Naegle,  Brad.  Developing  Software  Requirements  Supporting 
Open  Architecture  Performance  Goals  in  Critical  DoD  System-of-Systems. 
September  2006. 
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NPS-FM-06-034  San  Miguel,  Joseph  E.,  and  Donald  E.  Summers.  Using  Public 
Private  Partnerships  and  Energy  Saving  Contracts  to  Fund  DoD  Mobile  Assets. 
August  2006. 

NPS-AM-06-032  Apte,  Uday,  Geraldo  Ferrer,  Ira  Lewis,  and  Rene  Rendon. 

Managing  the  Services  Supply  Chain  in  the  Department  of  Defense:  Opportunities 
and  Challenges.  July  2006. 

NPS-AM-06-031  Hudgens,  Lt  Col  Bryan,  Capt  Carey  Petit,  Col  Rita  Jordan,  and  Lt 
Col  Leon  Mable.  Development  of  Measures  of  Success  for  Corporate  Level  Air 
Force  Acquisition  Initiatives.  July  2006. 

NPS-LM-06-030  Apte,  Uday  M.,  Nicholas  Dew  and  Gerald  Ferrer.  What  is  the  Right 
RFID  for  your  Service?  July  2006. 

NPS-FM-06-029  McCaffery,  Jerry,  and  Larry  Jones.  Reform  of  Budgeting  for 
Acquisition;  Lessons  from  Private  Sector  Capital  Budgeting  for  the  Department  of 
Defense.  September  2006. 

NPS-LM-06-028  Ferrer,  Geraldo,  Uday  Apte,  and  Nicholas  Dew.  What  Is  the  Right 
RFID  for  Your  Process?  July  2006. 

NPS-AM-06-027  Bowman,  Dan,  Lt  Col  Timothy  S.  Reed,  Lt  Col  Bryan  J.  Hudgens, 
Maj  David  Searle.  DoD  is  Not  IBM:  The  Challenges  of  Implementing  Strategic 
Sourcing  in  Defense  Acquisition.  July  2006. 

NPS-PM-06-026_Thomas,  Gail  Fann,  Erik  Jansen,  and  Susan  Page  Hocevar. 
Building  Collaborative  Capacity  in  the  Interagency  Context.  July  2006. 

NPS-CM-06-25  Donahue,  Capt  Kimberly  A.,  Capt  Joshua  M.  Parsons.  Government 
Imposed  Constraints  and  Forecasting  Analysis  of  the  M.J.  Soffe  Corporation. 
December  2004. 

NPS-LM-06-024  Lask,  LCDR  Gregory  R.  Advanced  SEAL  Delivery  System:  An 
Analysis  of  Product  Support.  July  2006. 

NPS-CM-06-023  Pigeon,SMSgt  Nanci  R.,  Lt  Col  Bryan  J.  Hudgens,  Lt  Col  Ellen  C. 
England,  Lt  Col  Leon  A.  Mable,  USAF  (ret.).  The  Use  of  Alternative  Dispute 
Resolution  Techniques  in  United  States  Air  Force  Environmental  Conflicts.  July  2006 

NPS-PM-06-022  Mark  Nissen,  Mark,  Frank  Barrett.  Changing  Major  Acquisition 
Organizations  to  Adopt  the  Best  Loci  of  Knowledge,  Responsibilities  and  Decision 
Rights.  July  2006. 

NPS-AM-06-021  Uchytil,  Capt  Joseph  S.  Assessing  the  Operational  Value  of 
Situational  Awareness  for  AEGIS  and  Ship  Self  Defense  System  (SSDS)  Platforms 
through  the  Application  of  the  Knowledge  Value  Added  (KVA)  Methodology.  July 
2006. 
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NPS-AM-06-020  Buchanan,  Cap  Steven  M.,  Capt  Jayson  W.  Cabell,  Capt  Daniel  C. 
McCrary.  Acquiring  Combat  Capability  through  Innovative  Uses  of  Public  Private 
Partnerships.  June  2006. 

NPS-FM-06-019  Jankowski,  LCDR  Patrick,  LT  Matthew  Lehmann,  and  LT  Michael 
P.  McGee.  Financing  the  DOD  Acquisition  Budget:  Innovative  Uses  of  Public-Private 
Partnerships.  June  2006. 

NPS-PM-06-018  Barnum,  Usher  L.,  Jr.  Business  Process  Re-Engineering: 
Application  for  Littoral  Combat  Ship  Mission  Module  Acquisition.  June  2006. 

NPS-AM-06-017  Mun,  Johnathan,  and  Thomas  Housel.  A  Primer  on  Return  On 
Investment  and  Real  Options  Analysis  for  Portfolio  Optimization.  July  2006. 

NPS-AM-06-014  Hatch  II,  William  D.  CDR,  USN,  Charles  Gowen,  AmerInd/FC 
Business  Systems,  and  James  Loadwick,  AmerInd/FC  Business  Systems.  Litoral 
Combat  Ship  (LCS)  Civilian  Aviation  Alternative  Support  Study:  Report  of  Findings 
and  Recommendation.  July  2006. 

NPS-AM-06-012  Meyer,  Jacqueline  M.  and  Sefa  Demirel.  A  Comparative  Analysis 
of  the  Department  of  Defense  (DoD)  Passive  Radio  Frequency  Identification  (RFID) 
Policy  and  Perspective  in  Terms  of  Site  Implementations.  June  2006 

NPS-AM-06-010  Rendon,  Rene  G.  Using  a  Modular  Open  Systems  Approach  in 
Defense  Acquisitions:  Implications  for  the  Contracting  Process.  January  2006. 

NPS-LM-06-009_Apte,  Uday  M.,  Nicholas  Dew  and  Gerald  Ferrer.  What  is  the  Right 
RFID  for  your  Process?  January  2006. 

NPS-LM-06-007  Mullins,  Captain  Michael,  US  Marine  Corps,  Captain  Troy  Adams, 
US  Marine  Corps  and  Lieutenant  Robert  Simms,  US  Navy.  Analysis  of  Light 
Armored  Vehicle  Depot  Level  Maintenance.  December  2005. 

NPS-CM-06-006  Cortese,  Captain  Casey  A.,  US  Air  Force,  First  Lieutenant  Heather 
Shelby,  US  Air  Force  and  Captain  Timothy  J.  Strobel,  US  Air  Force.  Defining 
Success:  The  Air  Force  Information  Technology  Commodity  Council.  December 
2005. 

NPS-LM-06-005  Hernandez,  Captain  Emeterio  V.,  US  Air  Force  and  Lieutenant 
Christopher  A.  Thomas,  US  Navy.  Investigating  the  Department  of  Defense’s 
Implementation  of  Passive  Radio  Frequency  Identification  (RFID).  December  2005. 

NPS-FM-06-004  Rios,  Jr.,  LCDR  Cesar  G.,  US  Navy.  Return  on  Investment  Analysis 
of  Information  Warfare  Systems.  September  2005. 
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NPS-AM-06-003  Komoroski,  Christine  L.  Reducing  Cycle  Time  and  Increasing  Value 
through  the  Application  of  Knowledge  Value  Added  Methodology  to  the  U.S.  Navy 
Shipyard  Planning  Process.  December  2005. 

UMD-AM-05-021  Gansler,  Jacques  S.,  and  William  Lucyshyn.  A  Strategy  for 
Defense  Acquisition  Research.  August  2005. 

UMD-CM-05-020  Dunn,  Richard.  Contractors  in  the  21st  Century  "Combat  Zone." 
April  2005. 

NPS-PM-05-017  Brianas,  Christopher  G.  Department  of  the  Navy  Procurement 
Metrics  Evaluation.  June  2005. 

NPS-LM-05-016  Doerr,  Kenneth  H.,  RADM  Donald  R.  Eaton  and  Ira  A.  Lewis. 
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